You can't "fix" the tls-sni-01 hole except by going back in a time machine to when Apache implements SNI and spraying all the involved developers with water. "No, bad developer, no biscuit. Do what the protocol specification actually says not whatever half-arsed nonsense you thought would work".
If there were like six web servers in the whole world that got this wrong, we could say "Fix those servers, fools" and sleep soundly knowing that those six servers are all that's affected. But Apache makes the scope too big to do that reasonably. It's a judgement call, but in this case the call was very easy.
But Let's Encrypt is part of the Web PKI, and the Web PKI is for all names on the public Internet, not just any operated by Jacques Mattheij. You sought certificates from the Web PKI, probably because you wanted somebody else other than Jacques Mattheij to trust them.
A large fraction of public Internet HTTPS servers run Apache, which means tls-sni-01 is unsafe for a non-trivial fraction of names, which means we need to tell Certificate Authorities not to use this method or those like it. Specifically 3.2.2.4.10. TLS Using a Random Number has to be approached differently if it's to be attempted. The tls-alpn-01 challenge implements 3.2.2.4.10 using ALPN instead of SNI and appears to be safe in practice.
There was this joke when I was a fledgling programmer 35 years ago: If engineers would build bridges the way programmers build software the first woodpecker to come along would destroy civilization as we know it.
I think your comment is a nice illustration of that.
To me if a piece of software has a problem then it is that piece of software that should be fixed, not to push the burden onto everybody else as well. That's just so wrong.
But that does not mean I don't follow your reasoning and understand why this decision was made, still, the amount of waste here is incredible.
My interest in cryptography and the Web PKI is part of my interest in how to improve things (and the intersection with my interest in the Network), so that means as well as reading about stuff like Bleichenbacher I am interested in bridges.
Contrary to what your joke suggests, bridges do fall down because engineers don't always do a great job or learn from previous mistakes, they are after all only human.
England (where I live) has many railway bridges constructed by Victorian engineers using cast iron. The Victorians were not necessarily careful to properly document everything about these structures. And so a modern engineering team, responsible for safety of hundreds of these structures has to make some assumptions or else it would need a tremendous amount of investment to either replace every bridge or take it to pieces to figure out how it was built.
One obvious assumption is, if you can get at the two cast iron beams on the outer edges of a bridge that's clearly supported on four beams, the two inner beams you can't reach without demolishing the bridge are presumably identical.
So on particular bridge, over a road, the routine inspection team climbed into the guts of the bridge, they measured the accessible outer beams and concluded these were of a sufficient thickness that, allowing for the inevitable corrosion by the elements and the permitted loading of trains, the bridge should be "good" for another 20-25 years before needing replacement.
The bridge fell down before the next routine inspection. Fortunately nobody was killed, but the collapse exposed that Victorian engineers as well as not documenting their design work saw an opportunity from the fact that the inner beams aren't accessible. They'd used cheaper, thinner metal for those beams and really the only problem with doing that is that bridge will fall down sooner than otherwise expected...
This wasn't Let's Encrypt's choice. The Web is secure due to a series of rules agreed upon between the browsers and the CAs. If vulnerabilities are found, there are deadlines for fixing them; in fact, the deadline for revoking misissued certificates is 24 hours, and Let's Encrypt couldn't prove existing certificates weren't misissued, but they were able to get away without revocations, which is a huge benefit for their subscribers.
The point of these rules are to keep the web safe. The choice here is between inconveniencing Let's Encrypt users (forcing some of them to upgrade or switch validation methods), but keeping the web safe, or making the web unsafe, period, forever (because there is no way to force users of broken web servers and web hosts to upgrade to fix the approaches to certificate management that caused this problem). The only reasonable choice was the first.
I had to change all my servers from TLS-SNI-01 to another mechanism, and I absolutely do not blame Let's Encrypt for this. They did the right thing.
If there were like six web servers in the whole world that got this wrong, we could say "Fix those servers, fools" and sleep soundly knowing that those six servers are all that's affected. But Apache makes the scope too big to do that reasonably. It's a judgement call, but in this case the call was very easy.