I fully agree! But that's a different thing. Of course the ability to quickly innovate is important, but you are implying that the current state of affairs is a necessary consequence. It's not.
I also like to "quickly innovate" by hacking some proof of concept code. Exploration is important and fun. I don't write a test first, or no test at all, if I don't even know yet fully what it is that I'm building or how the API needs to look like. But in the long run I can't keep going like that.
That's a superstition.
If you first spend 5 years crafting the perfect invitation to a date for your crush, then meanwhile another guy will have not just asked her out, but by that time they will have rings on their fingers, a house and two kids.
We may not have the internet we have today but I am not sure it would be for the worse. Some things would have probably slowed down, we may had also avoided the terrible flash/activex/javawebapp period but companies may had pushed for html5 earlier through standardisation process.
Most of the core IETF RFCs/BCPs are standardization of things already created. “Prior implementation and testing” is an explicit goal of the IETF process, so I guess you could argue that you’re following that process automatically by creating the initial non-standardized implementation.
I worked with the author of RFC 1149. He said it didn’t take him long at all to execute it.
Your idea to outlaw imperfect solutions is noble, but misses the fact that mature solutions learn from earlier, imperfect work.
If we’re fining or jailing people for releasing and/or using hacked together code, it either means no progress or rubber-stamp standards bodies that approve everything.
And I feel a little sorry for 13-year-old me, who presumably you would have treated harshly for releasing some BBS software that saw wide adoption when I “should have” invented IPv6 instead.
Why our industry typically fails to agree to formal standards is that it takes time and effort to agree upon standards. The W3C is a good example: browser vendors move faster than the W3C could keep up with, so they decided to bypass them.
I don't fully share your negativism towards this: the ability to innovate quickly is important, and even when things get fully standardized, there is no guarantee that every vendor implements them correctly (again, see HTML and just how different things can behave with different browser vendors that all use the same standard).