I can't really agree with this. The reason it's slow is because these are actively rendering components, being implemented in a game which was designed primarily for static blocks. You'll note that the class which allows for this has a particular name: TileEntitySpecialRenderer. Special being the key word. This is for special circumstances, where a block, for some reason, has a real-time 3d animation. A good use of this is a chest lid opening, or a piston extending/retracting. Vanilla Minecraft has very few instances of using a TESR, which is the point.
A TESR is not influenced by chunk updates because it's actively rendering every tick regardless of whether the chunk is updating. And let's face it, the OpenGL version has very little impact here compared to the CPU strain caused by all of this extra overhead of trying to render these objects. Render lists are pretty fast, particularly for the very basic geometry and texturing involved in almost any mod addition.
For 3d blocks which remain static and have no model animation, but still have a custom renderer, this can hurt performance during chunk updates as you mentioned. But in this case the modder is almost entirely in control of how efficient their code is to render their particular block, rather than relying on Minecraft's native methods of pulling textures for each individual face and computing lighting values and all of that CPU-intensive stuff. That doesn't mean they're going to be any faster, though, depending on what they do.
The bottom line is that anything other than static blocks are going to hurt performance, and there's no practical way around that in a game of this type. Tile entities alone weren't even made to be used as much as they are. When you stack special renderers on top, you can't hope for it to end well when you get as many fancy 3d mods and multiparts and everything that some of these packs have today.