Even if we accept that NAT is the right solution, it still is pretty limited in how far it has been able to extend the address space, since port numbers only give you two extra bytes of address space. And there are no further extra bytes to stuff somehwere else in a TCP or UDP packet header.

Of course, we could extend the address space by further breaking the layering of routes, and baking in support for higher layer protocols into routers. We can certainly stuff more address information in HTTP headers, so the web could be extended to essentially arbitrary size by simply requiring routers to look not just at source and destination IPs and source/dest TCP/UDP port numbers, but also client and server HTTP headers. SIP looks a lot like HTTP, so the same solution could work there. TLS already has support for additional headers, so we could also do extra NAT at that layer.

Hell, AWS could then use a single IPv4, and just rely on HTTP/SIP headers or TLS extension headers to know the actual destination! Of course, if you want to run another L7 protocol, tough luck - tunneling it is for you.

NAT is the problem that IPv6 fixes. Think about the parent comment

>if you are making more than 4B addresses routable then any existing IPv4 device will not be able to route some addresses, so you will have caused a split in the internet

This has basically already happened. We've massively extended IPv4 by stuffing extra address bits into the router's port number, and it means that any two devices behind NATs can't directly route to each other.