virtually all import/export plugins are written in python, which tends to be single threaded, so perf is less than ideal, there was a google summer of code student this year that was going to implement some of the importers (think it was .obj in his proposal, not fbx) in C/C++ which most likely would have meant an performance boost. But sadly the student had to drop out due to a competing offer.
As Ton Roosendaal mentioned there is a big issue with porting fbx because of it’s closed source, so blender has poor support for it. Also as @LazyDodo said, import-export features written as python modules and slow at big files. The official builtin format for blender is dae (Collada).
For some well documented file formats like obj, there are tailored scripts available, specific to the program you wish to do I/O to.
Some of those scripts can have up to 3x faster import or 2x faster export times.
Power is relative. Take several-hundred-thousand dollar super car, put it on a racetrack; yeah, that’s power. Now take it off-roading up a 60% grade. Or in traffic on a two-lane street; no difference between it and a Yugo. Take a first-gen Hummer on a race track; not so great performance. Take it up that same grade and it won’t even notice.
Reading from a file might be multi-processor capable for raw data. But if the content is inter-related, or it has to be processed in a certain order after reading, then there would only be a lot of threads sitting idle for others to complete. Exporting to a file will be even more so.