Lesson here is even though a car engine needs engineering before and during its construction, a game engine obviously needs no part of software engineering.
Nothing in this thread involves engineering.
Only perhaps this:
"I've only open sourced it as a favor to the indie community and I consider it just another feature. I never planned to make the engine as a commercial project so it only made sense to open source it. I'm not going to spend an excessive amount of time making the code readable to others. Right now I have no problem reading and debugging my own code."
There is a goal with means to achieve it. Engineering aspects now involve evaluating how current approach addresses the desired outcome.
The goal is to please indie community. So in order to evaluate quality of engineering, the intended target audience needs to speak about their experience in using the library to build whatever they want to. Maybe they will complain about code, maybe they won't.
Features are also binary. Either something is present and used or the engine isn't usable. Just adding features not *required* by target users is indeed a waste.
Could improving readability help with debugging and development? The question is distracting - are users using this engine having troubles? If so, are these problems related to code readability of the engine itself?
There is correlation between most of what was said in this thread with what most consider to be software engineering. But neither of those is what it seems. The purpose of software engineering is not, nor has it ever been, source code. Or anything related to source code. Or even software. Never, in history of computing has any user said: "the proper indentation of for loops proved to be the driving force behind our project, only second to properly capitalized variables".
Correlation is not causation, just applying it blindly is cargo culting.
Reason why some successful project seem to succeed because of such good practices is not that - they do so because they are composed of greatest coders who have plenty of time and mental power to focus on all tiny details.
To give an example - if notch were still following all Java best practices, his code today would be only 15 million lines of code and only 1/4 done.
I only skimmed, but I don't think anyone in this thread said: "Can I import 3DS directly? How do I build it on Mac? Why can't it do dynamic shadows?" Those are the important parts that only users who use the library for intended use can provide. The rest is gravy, unless it prevents timely delivery of said features. Such as when 700-line function requires spending 6 weeks on adding a feature when users need it in 3.