This is fine, HTTP is probably the largest layer 7 protocol on the internet, but if you were to design a layer 7 protocol that needed a lot of the features that TCP provides it would be quite dump to reimplement them yourself on top of UDP.

you care about the data, you want it to arrive in order, and you need it arrive. You want to be notified if there is a problem at the other end. You want the data sent to match exactly the data delivered.

File transfer, simple protocols, advanced critical protocols. Anything where the dev doesn't want to think about how to account for packet loss. Its already done for you in a standard interface.

Why you want UDP:

You want the latest packet of data, and you want it now. it doesn't matter if you lose a few packets. Telephony is the classic example. if you loose a frame its not the end of the world. Streaming video is another, Use FEC to cope with loss.

Tedious real world analogy:

When you send a letter or a parcel, you have two options: Send it recorded, and pay slightly more per go, but not have the worry about phoning up the recipient to see if they received it.

However if the letter is of little worth (like a flyer or something similar) then the notification and or guarantee that it has/will arrive is a pointless cost.

In addition to reliability, TCP provides congestion control which provides approximate fairness of bandwidth utilization per connection. Fairness here meaning given a limited pipe of size W each connection gets a W/N slice of the pipe's available bandwidth. I don't know that I'd like to live on an internet where every hipster made their own decision about how to handle congestion control, see also congestive collapse.

Unless they had access to a tier 1/2 network provider it'd be mostly harmless I suspect. They'd spam their local gateway. "Look I can send 300k packets a second over standard DSL"

But yes, TCP is generally a good thing.

Which is why the "default" protocol for most things is still TCP.

Many, many applications deal much better with loss than they do with delayed retries. You don't want a VOIP app to perfectly recreate what the other part said 30 seconds ago, games usually only care about current state, and so on. In many of those cases, TCP is the wrong choice but a lot of people use it out of familiarity.

Remember, UDP came after TCP. One isn't "better" than the other and they serve different requirements.

Would you rather wait for a transmission of the missing position update 1 sec ago or just forget about it and continue processing the next one ?

In this context, you'll prefer the second option. It will probably cause a visual glitch but the game can go on, and players will say "lag" :)

It still won't change the fact that application needs won't always match TCP exactly. And that's the whole point.

And, with a bunch of per-site monitoring frontends with batching, compression and deduplication, thrift/protobuf and long-running connections, the TCP overhead is meh.

Serious exceptions, sure, retry. But serious exceptions are rare. What's not rare is sampled memory usage, cpu usage etc..