The answer provided in the linked comment isn't very thorough, so here's a better explanation.
IPsec is used by itself (sometimes referred to as bare IPsec) all the time; it is commonly used to create a secure transport link between two machines, or to create a tunnel between to different networks / POPs; the former is used (as mentioned) between two machines, while the latter is used to connect disparate networks together, especially when the networks are in RFC1918 space. However IPsec is a very flexible standard (especially v1 over v2), and doesn't establish much in the way of rigid requirements for getting the two endpoints talking to each other. In the situations above, this isn't much of a problem; you simply define all the parameters between the endpoints manually (encryption algorithms, hashing methods, network declarations, as well as upper level routing protocols).
That's all fine and good, but what happens when you want to use IPsec in a road warrior scenario? Let's say you have an employee who wants to connect to the internal network but is traveling, and you want to use IPsec. Do you have him manually configure those things all the time? Is he/she even capable of identifying what network he's on if he's using something like a public wifi gateway? Do you expect him to set up addressing and routing protocols every time he connects?
Of course not. That's what the IPsec + L2TP standard is for. This builds on bare L2TP (also a pretty barebones defined protocol) and automates all of that: it establishes hashing and encryption standards as well as defines a way to leverage PPP over L2TP to do the actual network and routing bootstrapping so that all a person has to do is enter their credentials and hit "connect" (you did know PPP was involved, right?). Think of IPsec + L2TP as something comparable to PPTP, except it's not considered insecure.
A little more in depth to visualize better: think of the end user being a person dialing into an old ISP. L2TP is the phone line / layer 1 / physical connection, as it allows layer 2 protocols to operate on it. When you dial the modem (connect to the endpoint), PPP is the protocol that runs on that link to authenticate you, get you an IP address, as well as routing and DNS resolving information. You're now online. IPsec + L2TP is exactly the same, except instead of a phone line, you're creating a virtual circuit across the internet (L2TP), and to keep it secure, you're encrypting that circuit with IPsec. This encrypting part happens first, before the L2TP connection is made, but everything from that point on is exactly the dialup analogy.
To go even more in depth: why use L2TP just to get PPP? Why not just run ethernet frames instead of PPP on top of IPsec to use traditional things like DHCP / OSPF? Actually you can: bare IPsec is designed to offer full layer 3 connectivity except for multicast / broadcast; so in the case of DHCP and OSPF, you'd probably swap out L2TP for GRE. Why isn't GRE used for mobile users? Because it doesn't offer authentication, while the IPsec + L2TP standard does (don't ask why we picked L2TP over GRE for the standard). PPP fits better for that scenario, although GRE over IPsec is used in other situations. And if you don't need ethernet framing at all – just doing things like standard applications (web browsing, etc) or utilizing BGP – you don't need any layer on top of bare IPsec.
So in short, you usually use bare IPsec when you have static configurations between two endpoints. You use IPsec + L2TP for dynamic (mobile) end users who have little control over their environment.