Both have their pros and cons. Of course TCP isn't essential, it's just handy when it comes to sending data reliably.
If data goes missing, TCP will retransmit the data. This is the key concept of TCP.
RFC 793
UDP doesn't follow this same concept. The idea for UDP is to avoiding waiting by removing the need for a retransmission queue. This means data might be lost, but in the right enviornment, that's just fine.
Example
Imagine you're playing Call of Duty.
It's important to send information anytime change occurs between clients. The angle difference the player's camera, the difference in location, etc.. Anything that may affect the player's gameplay must be logged to ensure top notch performance. That's a lot of data.
This means it's not wise to wait for data, as there's quite a bit of data that needs to be transmitted. So you must be wondering about the missing packets: how can programs run properly when packets go missing?
Keep in mind how fast these packets are being sent over. If one goes missing here or there, it's fine, as there's another slightly different (but not too much different) one coming along the way.
As for that small timeframe of missing,
dead reckoning covers it by simply reusing the last frame of data. It continues using that data until a new update packet is sent. In UDP, packets aren't lost as often as you think (maybe around 1-2%), so as long as your network logic is sound, you won't even notice.
But dead reckoning can't be applied in all situations. If your game isn't constantly sending data over, then you'll want reliable data. As S Quare Quxx mentioned, you may find yourself using both: UDP for game world, TCP for chat, or something along those lines.