TCP wont always deliver your packets anyway , but it does have a mechanism of timing out if a party believes the other party did not receive something. UDP just means that if one cares for their data to be received, they must verify it themselves.

Yes, it's not so much 'reliable' or 'best effort', rather the difference is 'which part of your software stack should deal with dropped packages'?

That's in my opinion what reliable / unrealiable mean in this context.

reliable = it either succeeds or you get an error after some time, unreliable = it may or may not succeed

I concur with the people who think "best effort" is not a good term. But perhaps TCP streams are not reliable enough for TCP to be rightly called a reliable stream protocol. As it turned out, it's not really possible to use TCP without a control channel, message chunking, and similar mechanisms for transmitting arbitrary large files. If it really offered reliable streams that would its primary use case.

the designers of link layers and protocol implemntations, the army of operators who test signals, insteall repeaters, configure routers and hold conferences about how to manage the global routing system would disagree.

best effort implies 'no, we're not going to be climb that curve and get try to get to 100% reliability, because that would actually be counterproductive from an engineering perspective, but we're going to go to pretty substantial lengths to deliver your packet'

In a way, TCP is just about as reliable as UDP, but at a different layer: TCP will either forward your entire stream of data in order and without gaps, or it won’t. UDP does the same, but on the per-datagram level.

Reliability is arguably more of a statement about the availability metrics of your underlying network; it doesn’t seem like a great summary for what TCP does. You can’t make an unreliable lower layer reliable with any protocol magic on top; you can just bundle the unreliability differently (e.g. by trading off an unreliability in delivery for an unreliability in timing).

As another reply points out, it has a useful and well-formed meaning, even if you don't like it.

UDP is at-most-once; TCP is exactly-once-in-order.

There is minimal effort. If the queue has room the packet gets forwarded. If the situation is any more difficult than that the effort ends and the packet is dropped.