You can primarily speed up your code by refactoring it and implementing faster algorithms.
Instead of performing intersection tests on every box, you could for instance first find the immediate neighbourhood of your sphere and only perform the intersections on these boxes, instead of all the boxes.
In order to find the closest boxes to the sphere, you could evaluate distances. You know the radius R of your sphere and the radius D of the outer sphere of each box (box diagonal / 2). A box and the sphere can thus only intersect, if the distance between the sphere center point and the box center point is smaller or equal to the maximum distance R + D. The boxes found within that distance form the immediate neighbourhood and are evaluated for intersections.
If you want to optimise even further, you can implement the R-tree algorithm, available in rhinocommon, which does a similar thing to what I’ve described above, but much more efficiently.
You could also implement parallel computing. However, multithreading is oftentimes inferior to R-tree. When the bruteforce method, checking each box, needs n time to execute, parallel computing only speeds that up by a factor of n / p + log2p (p = processor cores), whereas R-tree for instance offers a speed up factor of n/log2n .
A very simple and straightforward way to test execution speeds of code portions is using time.
start_time = time.time()
# Your test code
elapsed_time = time.time() - start_time
problem points distances to breps 03.gh (15.4 KB)
Your script works for me without issues! When the sphere intersects a box, it print True. If not, it outputs False. It seems to be totally fine!