This counter-argument fails because HTTPS is much easier to implement and web servers already use it. Whereas TCP is much lower level and to make "STCP" we would have to recode servers entirely to handle both TCP and STCP requests from clients.
TCP is a transport level protocol. It's job is to get messages from A to B in a way that tries to guarantee delivery (amongst other properties). HTTP is an application level protocol, it's job is to encapsulate messages and commands between two applications that may be remote. We have already built mechanisms that secure traffic on the transport layer (see IPSec) and they actually work well when they're needed/useful. It turns out that right now, securing data on the application layer is much easier / cheaper than trying to do IPSec everywhere.
Finally, HTTP is a bit of a special case, because much of the time data delivered over HTTP is code that's going to be executed on a client's machine. If anything, this makes it much more important that the integrity is preserved.
Cryptography cannot be separated from authentication, and only the application can know how to do authentication. E.g. emails are designed to be forwarded between servers and not care about the exact path they take, so it would be foolish to apply hostname-based encryption to emails; instead emails are (or should be) encrypted using S/MIME or OpenPGP, to the specific intended recipient. It's then fine, indeed desirable, for these encrypted emails to be passed around over cleartext transports such as TCP.
> Cryptography cannot be separated from authentication
Frequently repeated but still wrong. Cryptography requires one of the following:
1. Two key pairs, or
2. A shared secret.
The shared secret implies authenticity. But there are entire classes of cryptosystems based on not knowing with whom you are communicating. Crypto establishes a channel through which Alice and Bob can then negotiate authenticity. (To put it in simple terms: it's better to be phished over secure transport than to be phished over plaintext.)
For some reason, a large number of people seem to have completely skipped over this basic advantage of unauthenticated channels: you have now isolated the communication to you and your prospective phisher. This is a gain, this is an advantage, and it borders on absurd that people go to such lengths to deny this.
Cryptography without authentication still provides protection against (non-MITM) eavesdroppers, which is very important with public wifi networks nowadays.
Which is why it's strange that self-signed connections are represented to the user as dangerous, while unencrypted connections do not have such a warning even though the former is strictly better.
Public WiFi is the anti example since if you can read to the WiFi, you can write to it and MITM connections. Passive is probably best, right now, against large scale fiber taps. And only as a stopgap.
If that's the argument, it reasonably applies to everything, everywhere, and we should scrap TCP alltogether.
Instead we need to implement a replacement which ensures everything everywhere at every level of every stack does crypto as well. Let's call it STCP!
Or does that suddenly sounds zealous? It just follows from your base argument.