It uses UDP to get through stupid NAT devices. What's happening here is that the actual IPSec traffic is being encapsulated in UDP (IP protocol 17). The native IPSec packet would have an IP protocol header-value of 50. Since 50 is neither UDP (17) or TCP (6), stupid NAT gateways will drop the packet rather than pass it.
Secondly, since IPSec is neither TCP or UDP, it doesn't have a port-number. So if you're at a very large conference and eight of your coworkers are also going, only one of you could have your VPN up at any time as the VPN Concentrator only does IP-level disambiguation. By encapsulating inside of a UDP packet, it allows multiple VPN end-points behind a NAT device.
As for why UDP? That's described in RFC 3715. Section 2.1.b:
Incompatibility between checksums and NAT. TCP and UDP checksums
have a dependency on the IP source and destination addresses
through inclusion of the "pseudo-header" in the calculation. As a
result, where checksums are calculated and checked upon receipt,
they will be invalidated by passage through a NAT or reverse NAT
As a result, IPsec Encapsulating Security Payload (ESP) will only
pass through a NAT unimpeded if TCP/UDP protocols are not involved
(as in IPsec tunnel mode or IPsec protected GRE), or checksums are
not calculated (as is possible with IPv4 UDP). As described in
[RFC793], TCP checksum calculation and verification is required in
IPv4. UDP/TCP checksum calculation and verification is required
This can happen since the IPSec stack itself has integrity checking, so using an 'unreliable' protocol to transit networks does not present a critical breakage in functionality. If a packet gets scrambled in-transit, it won't de-encapsulate right, and the IPSec protocol will correctly handle that case.
Some clients do support TCP mode, but Cisco isn't one of them.