As an aside: I'm quite convinced that an extremely precise version can be implemented that is significantly faster than Karney's, roughly comparable in speed to simpler naïve approximations. But for most purposes where the precision matters Karney's implementation is not any kind of bottleneck, so it's not clear it's worth spending significant effort on trying to do better.

Maybe that's something one of the big LLM companies might want to throw their machines at optimizing if they need to do a lot of geographical calculations.

One of the places where Karney does become computationally expensive (though still not ridiculous) is a scenario like this, working from a local in-RAM mariadb database that is a copy of the entire FCC radio license database:

Draw a 400x400 km size bounding box on a map

Find all FDD band plan (high/low split) microwave radio sites in that bounding box

Find those sites which have azimuth aim column data which indicates that they are aimed at each other (corresponding halves of a point to point link).

Do Vincenty (or Karney) calculation for distance and azimuth between all of them , treating the existing FCC column data for azimuth as suspicious (because it's hand entered by humans) to verify that each independent database rows for each site are actually corresponding halves of a PTP link.

Use various other logic to group the successfully matched halves of links together as points A and B of PTP links, and write them out to a geojson file with placemarks and line drawn between them.

Multiplied by the number of links that exist in an area like a 400x400km box drawn with Dallas, TX as the center, it's a lot to run through Karney. Actually does result in a lot of CPU load from combined db query due to the size of the db, and Karney calculation. But as I said, Karney isn't necessary, so it's instead implemented as Vincenty.