From my own experience I know that using bvhtree.ray_cast(...) and similiar functions is always a bit annoying.
This is because these functions return a tuple and I always have to look into the documentation to find the correct order of the returned elements.
In Python namedtuples are there to solve this problem. A PyStructSequence in the CPython C API is the C equivalent of that.

This change breaks scripts that expect that bvhtree.ray_cast(...) and bvhtree.find_nearest(...) return a tuple when no surface point is found.
Instead of returning a tuple in that case, just None is returned. In my opinion that works much better in practice.

I haven't tested it but I don't expect there to be any noticable performance impact. We might even be able to speed it up later on by lazy generation of mathutils.Vector objects. I don't think this complexity is necessary atm. If we really want this api to support very fast access we should have new api functions that allow to run many queries at the same time + they should support the Python buffer protocol.

hit = bvhtree.ray_cast(origin, direction)
if hit is not None:
    do_something(hit.location, ...)

nearest = bvhtree.find_nearest(origin)
if nearest is not None:
    do_something(nearest.normal, ...)

When this patch is accepted, I'll update the already ported addons that use the bvhtree.
Furthermore I'll do the same change mathutils.KDTree.