1.5 had to change due to the long-needed introduction of a dynamic texture atlas. Minecraft itself changed, and Forge needed to adapt rather than write in a bunch of code to support a legacy system that wasn't there in vanilla.

This is still a different situation. The custom rendering functionality is there, in Minecraft, right now. Fluids use a custom render ID through it, because it's far too dynamic to want to use models for it. And this is sound reasoning.

With Mojang's reasoning in mind, for times when a block is simply too dynamic to expect models to be used for it, why did Forge take the complete opposite approach of forcing mods to go through the model system, with absolutely no alternative? It just wasn't designed for this, functionally or performance-wise. Models are only supposed to be baked one time and stay in memory until a resource reload. That's where they got their performance gain. When you create dynamic models, and then send them through this system, you're losing performance compared to if you used a direct render hook to begin with. Directly using the tessellator, or using the model system in a render hook to render pieces of models based on state, would still be unquestionably faster.

Forge seems to be adamant that ISmartBlockModel is the future of Forge, when it was implemented from a fundamental misunderstanding of how rendering worked. This is why another workaround is now necessary to avoid threading issues. How does that make any sense?

Marking the old system as deprecated, as well as the fact that block rendering functionality was gone, would have been more than enough to imply to modders that a new means of rendering would be needed in the future. But it would have given them time to adapt. Instead, we ended up with this drastic divide between 1.7 and 1.8, where Lex just can't seem to understand why modders won't update, other than than being idiots in his mind, when in reality 1.8 is functionally inferior.