The cleaner architecture is the whole point of the exercise.
I'm trying to avoid arguments why this would be "better" than anything else. Just some examples of things that I personally don't like about IP, and that Ouroboros does differently. These points may not matter to you, and that is perfectly fine. I'm not a salesman trying to make a sell.
1) IP (and Ethernet etc) has source addresses in every packet. Ouroboros negotiates them at the start of the communication, and only has the destination address in the packets. This improves end-user privacy a great deal.
2) The Ouroboros end-to-end protocol, (which has the RTT estimator and retransmisison timeout (RTO) timer), runs in the library between the actual server and client programs. It runs at sub-millisecond accuracy. If there is an underestimation of RTT, at worst it retransmits a few extra packets (See 3). But these improve the RTT estimate.
3) Default TCP congestion control doesn't play nice in lossy situations, having severe issues with throughput because of AIMD. Ouroboros completely splits the network and end-to-end protocol. Therefore the architecture only allows congestion control using Forward ECN at the network protocol (and only the network protocol). This is similar to the operation of DCTCP, but DCTCP has the ECN in the network protocol (IP), and the notification in the end-to-end protocol (TCP). I'm not fond of that as a solution (however, if I would run a commercial datacenter, I would run DCTCP, no doubt about that).
4) The Ouroboros end-to-end protocol is based on Delta-t, which doesn't require the 3-way handshake of TCP. It does have a two-way handshake (called flow allocation) to negotiate endpoints and the peer addresses (as to avoid sending src in every packet). But it can also do a ECDHE key exchange at that time. So it can establish an encrypted end-to-end connection in 1 RTT. The implementation still does it in 2 phases, (it's on my to-do list to piggyback the public keys).
5) Ouroboros has 2 types of layers, one for unicast and one for broadcast. This is where I think it really shines. The broadcast layer allows easy implementation of what is known as a "multicast service". A PoC is in the obc program.
Some of this may still seem nebulous, and I apologize. It's an unfunded pet project. But if I find interested people that ask interested questions, it will help me to update the documentation and make things more digestible/palatable.
Thank you again for your interest.