No, I have not worked on this any further, but I have some more thoughts on the topic of handling larger maps:

The number of iterations is the better heutristic, as the limiting factor is the iterations on the CPU and because we move along a grid with a fixed distance most of the time the distance roughly translate into the number of iterations. So number of iterations is already defining the max. distance but dependent on the number of iterations (CPU-cycles) you have and not an arbitrary distance.
based on your big grid sample a smaller grid (e.g. only a 4th or 8th of the size) and find the shortest path on that map, afterwards run an optimization algorithm on the path to avoid only moving along the roughs grid edges. Note that this might not find the shortest path as you have to mark the whole area as non-passible if there is just one obstacle in your detailed map.
for special cases like implementing a motorway/highway or some other logic handling long distances on a map you need to introduce additional knowledge into the algorithms and want probably to write a custom algorithm instead of using this.
As discussed in Performance issue with node.py #53 getting faster would require a rewrite of the library with numba or other libraries which might shift the focus from supporting general pathfinding to less generic solutions.

Limit by maximum distance #20

Description