This explanation doesn’t sound simpler at all, it sounds like the complexity (each computer runs multiple services) is just obfuscated by making it part of the IP address. It would make routing a nightmare since the router now needs to keep a table of all services running on all hosts to know where to route traffic.
Routing would be no different. Routers already work with IP address prefixes. In the scheme described, a computer's IP is just a /32 prefix of a 48-bit address, and serves as the router for the 65k addresses.
The biggest difference is language - we don't have to think about addresses and ports being different ideas. Our APIs and textbooks get simpler.
And from an address perspective, its better because we end up with much more flexibility around how our networks are designed. Want to use 1 public IP address with 10k web servers? Now you can! Want a single machine to handle 10M outgoing socket connections? Sure - just allocate more addresses from your pool.
You can already do some of this stuff right now, but its awkward to reason about because of how ports and addresses interrelate. It'd be simpler and easier if we just think of the (address,port) tuple as a single address entity.
The main difference is that 'ports' live under the protocol layer (TCP/UDP/...) - TCP port 22 and UDP port 22 are not in the same address space
In many way's it's a very historical thing, back when TCP/IP was one of many competing network architecture (early 80s) most of the competing architectures did it the other way (there was only one port at that level and protocols ran under that). Is one better than the other? probably not much - TCP/IP won (IMHO) because they understood datagrams vs. virtual cicuits - they didn't plan on charging for TCP or IP level retries.
