The problem is multiplexing IKE and ESP on the same UDP port. To distinguish between the two protocols one or the other has to be marked somehow (otherwise some potentially error-prone heuristic had to be employed).
So continuing on UDP port 500 would have meant to mark the ESP packets as non-IKE packets, in order for the recipient to properly decide whether to process a packet as ESP or hand it to the IKE process. The first two drafts of UDP Encapsulation of IPsec ESP Packets (RFC 3948) actually defined it that way. An all-zero eight byte non-IKE marker in the location where the initiator's IKE SPI is stored in IKE packets was defined as prefix to the actual ESP packet (between UDP header and ESP header).
The problem with that was, of course, that there are usually a lot more ESP packets than IKE packets and imposing an overhead of eight bytes (in addition to the UDP header) to every one of them was not ideal.
The alternative was to mark the IKE packets, which is what version 02 of the draft defined and eventually ended up in the RFC. An all-zero non-ESP marker of four bytes in the location where the SPI is stored in an ESP packet is inserted between UDP and IKE header.
However, that meant port 500 couldn't be used for such packets because all IKE messages (even the first ones) would have to be marked that way, which wouldn't have been backward compatible to IKE/IPsec implementations that didn't support NAT-Traversal. Instead, a separate port is used for UDP-encapsulated ESP and IKE with non-ESP marker. And in order to create a mapping on the NAT before any UDP-encapsulated ESP packets are transmitted (i.e. so inbound traffic can be processed even before any outbound traffic is sent) the switch to port 4500 happens as soon as IKE detects that a NAT is present.