After doing a bit of a deep dive into trying to isolate the bottleneck, it's still pretty unclear. I was able to replicate OP's claim of 5x slower for User Specified fonts, even though it was just Arial font I was using as User Specified. But there was inconsistency across test machines.
Creating a simple test of the Get Text Rect in a For Loop and running it 1000x showed User Specified as much slower than Application or System fonts, but what's odd is that if you Continuous Run that test VI and then watch the milliseconds per 1000 loops, you can observe it be slow, then open the Performance and Memory Profiler, and it instantly gets faster, on par with the Application Font, without even starting the profiler (the window call was enough to kick it faster). Then it doesn't slow down after that until you quit LV. Same effect occurs if you have a "Save as...:" dialog pop up, it instantly speeds up, and stays fast. So there must be some sort of call under the hood to suddenly get the system to tell the DLL inside GetTextRect to cache the User font stuff.
So, there's probably a lot more digging that could be done, but for now, I'll see if I can use the Get Text Rect VI more judiciously in my application. I like the caching idea as well, but with the kerning in quasi-random text strings, that could be a real headache.
Thanks for the rapid response!