Why doesn't anybody use TLS VPN?

Many VPN protocols do use TLS. In particular, almost all of the modern client-server VPNs (e.g. used to connect a laptop remotely to a corporate network) support TLS as a primary or fallback transport. I'm a contributor to the well-known open-source client for TLS/SSL based VPNs: openconnect. I reverse-engineered the GlobalProtect VPN protocol (TLS+ESP) almost entirely on my own. I've studied enough VPN protocols in detail to notice some pretty clear patterns and design tradeoffs.

Advantages of TLS for VPN authentication and transport:

Robustness. TLS-based VPN traffic is indistinguishable from "normal" HTTPS traffic in terms of its packet structure and encrypted contents — though timing and size of packets, and duration of connections, hint that it's carrying something other than "normal" browser traffic. The universality of HTTPS means that TLS-based VPNs can get through almost all firewalls and middleboxes; only really determined censors who do traffic analysis, or blacklist VPN endpoints by DNS or IP, can block it. Strong security guarantees: modern TLSv1.2 (soon, 1.3) is a very well-designed, carefully analysed, and gradually-matured protocol for secure communications. Many libraries wrap it in a way that makes it fairly hard to misuse. If you use a TLS-based VPN, you can expect that your connection to the gateway uses modern ciphers (no ancient 1DES, for example) and x509 public-key certificate verification of the gateway, limiting man-in-the-middle attacks. It's possible to screw up the implementation of TLS, badly breaking its security, but relatively difficult due to the standardisation of high-quality libraries which do most of the tricky bits. It would be much, much easier to write an insecure VPN based on a "custom" protocol.

Disadvantages of TLS VPN transport, compared to ESP (the normal transport layer of IPSEC-based VPNs):

TLS normally runs over TCP, which performs poorly as a tunnelling transport with congested or lossy underlying network conditions… especially in the case of TCP-over-TCP. Fortunately, DTLS ("datagram TLS") can alleviate this; it's used most prominently in the AnyConnect/openconnect VPN protocol, as well as in real-time communications protocols like WebRTC. Most modern operating systems have optimised in-kernel support for IPSEC and ESP. This makes ESP really efficient and low-overhead for gateways and firewalls and end-client systems, when implemented properly. TLS is typically implemented in userspace, and combined with the complexity of the underlying TCP stream, this makes it less efficient.

(A similarly efficient in-kernel implementation of DTLS should be possible, but I'm not aware of any in a mainstream operating system.) … as far as using TLS for the authentication/setup of a VPN? I basically see no real disadvantages there, other than the lack of standardised protocol for it. TLS is more flexible, widely-implemented, and easier to debug than ISAKMP (the authentication/key exchange component of IPSEC). Several modern corporate VPN protocols, including GlobalProtect, use TLS for authentication and key exchange but then ESP for data transport (though they can fall back to TLS if needed). This is a pretty effective and efficient combination, in my experience.