You mix things up.
First, there is nothing against a service on multiple IP and the user being smart enough to use one that works.
Second, bonding is not based on IP - bonding works on the ethernet level. A bonded connection shares one mac address. It basically IS one connection. As such, they do not really share one IP - they are one ethernet channel. THis is "more fundamental" - bonding works on the underlying technology.
Third, bonding does not work cross switch. Or: if it works like that, then basically it requires the switch to know how to handle this (stacked switches may have this capability). Which means you can say goodbye to most lower cost switches for bonding and uptime. Not sure about some higher end, but I am not knowledgeable of any one that can handle bonding distributed over multiple chasses. Not THE specialist, though - but I also generally move to 10G before using bonding. Cisco, I hear, has this capability (Cross Switch LACP).
Generally bonding is used to create more bandwidth TRANSPARENTLY for applications not written with this in mind. Protocols that are built for high throughput and uptime may not need bonding - for example ISCSI handle this with MPIO (MultiPath IO) where it actually connects to a server via multiple IP addresses, distributing load and handling uptime this way. Microsoft does the same now with file shares in the later servers, allowing multiple IP addresses to be used to handle multiple parallel streams of data for more bandwidth (SMB 3 MultiChannel). No need for bonding here, all handled on protocol and library level.