Simply because IPsec was not built to initially include a Key Exchange. In fact, early implementations of IPsec expected you to manually configure an IPsec Key, from which Encryption and Authentication keys were derived.
When it was determined manually setting and rotating keys would not scale, they looked to find another solution, but one that didn't involve re-writing every IPsec implementation.
So now, you have the ability to manually configure IPsec keys (archaic, no one does this anymore, neither should you), or you can use ISAKMP to auto-magically provide keys to IPsec.
ISAKMP (Internet Security Association and Key Management Protocol) exists for the purpose of securely establishing keying material, over an insecure medium (Internet), for IPsec to use.
But that is not all ISAKMP does.
IPsec also wasn't written with a direct Authentication method -- verifying the other end is who they say they are. The initial idea was if both parties manually configured an IPsec key, and both parties manually configured the same session key, then clearly if they reproduced that key they are indeed who they think they are.
But if those same IPsec keys are being auto-magically determined across the Internet, then there needs to be a way of first validating the other party you are securely exchanging keys with is who they say they are. Which is the other part of what ISAKMP does.
So, ISAKMP (Phase1) is primarily responsible for validating the other party (securely), and generating keys for IPsec to use. Then IPsec is primarily responsible for securely transferring data. What ties both of these protocols together, is the Internet Key Exchange, or IKE.
There are more details in a write up I made over on Reddit when someone asked "Why is secure tunnel established in ike phase 1 not used for data transmission?"