It's perfectly possible for something to both be incredibly popular and to suck. An appeal to popularity is certainly not better than a click-bait headline.
I'd argue that most of the stuff we use sucks in some ways as well; suck isn't an absolute term. TCP sucks in very specific ways the article talks about.
Compare “TCP Sucks” (easy to read—communicates, concisely, that this is an opinion piece, and what the opinion is)
or “Limitations of TCP” (misrepresents the article as informational)
(Also, if you're designing a communications system, don't give it the same name as another communications system.)
TCP has its limitations, of course. It was designed to work over a wide range of connections, including dial-up, and it does. It's suboptimal for broadband server to client connections where big server farms from a small number of vendors dominate. Hence QUIC and HTTP/2/3. Still, those don't provide a huge improvement in performance.[1] Even Google merely claims "on average, QUIC reduces Google search latency by 8% and 3.5% for desktop and mobile users respectively, and reduces video rebuffer time by 18% for desktop and 15.3% for mobile users." That's marginal. An ad blocker probably has more effect.
The author is worried about the overhead of the three-way handshake, but the overhead of setting up TLS is far worse.
[1] https://conferences.sigcomm.org/imc/2017/papers/imc17-final3...
Well that won't be confusing at all:
* https://en.wikipedia.org/wiki/Iridium_satellite_constellatio...
Oh, "TLS sucks" is a whole separate blog post for another day ;-)
I’ve tried to design stream transports on top of UDP. It is doable if the scope is narrow and you actually understand a bit of what went into other protocols (like TCP). But it isn’t easy.