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.
I'm intimately familiar with cases where you actually would prefer to use UDP. My point is most of the time these cases aren't what you're dealing with.
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.
>every hipster made their own decision about how to handle congestion control
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"
That's completely dependent on the application. SNMP over TCP would be a net loss because 1) it doesn't buy you anything as SNMP doesn't have any requirements that TCP meets above what UDP provides, 2) TCP would be exceedingly expensive, requiring connection buildup and teardown, ACKs, etc., and 3) it's way easier to implement UDP than TCP, so dumb devices basically need to only construct a single Ethernet frame to make it work.
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.
