IPSec uses IKE for a key agreement between two endpoints. Here the key agreement protocol uses a separate UDP based transport channel. The data from applications is not sent through this UDP port.
Actually, I see two incorrect statements here
IPsec doesn't always use IKE to do key agreement. Quite often it does, however there are real world implementations where IPsec is used with some other protocol.
Even if IPsec and IKE are used together, sometimes they use the same UDP port. If they're are using NAT-T (RFC 3947, 3948), then all the traffic (both IKE and IPsec) will go through the same port.
However, to address your question:
Why TLS designers chose to use same transport layer port for both handshake and application protocol?
I'm not Eric Rescorla, however I suspect they never really considered the possibility of using two separate ports for control and data. If they had, they would have immediately seen that, for them, using one port was better because a) it simplified things for them, and b) they had no reason not to.
As for the simplified, for one, there's no ambiguity in the control records as to which data channel they're talking about. In addition, TLS assumes that records flowing in the same direction are delivered in order, hence they don't need to worry about situations where they issue a control record, and then a data record, and the data record arrives first. If they used different TLS ports, that would be a possibility that would need to be addressed.
What would be the implications if a TLS like security protocol is designed to run handshake and application protocols to run on different transport layer ports?
There would need to take care about the concerns I mentioned above (not too hard), and they would also have to worry about middle boxes (firewalls, NAT devices) getting confused about the relationship of these two not-obviously-connected TCP flows.
