Programming

The client is packaged and sold with the VPN subscription to "add value". People like you and I understand that VPN clients are pretty simple places of software, but most VPN customers, well... you know

You're not missing anything. Mullvad and probably some of the others lets you download a client config and use it in whatever app you want.

The ones that don't allow that are probably shady or just don't care about your freedoms, behind a guise of "our app is more convenient/safe/etc".

There are business, technical, and UI/UX reasons for having a client. The business case is that it clearly demarcates the service they're selling, because it must be installed and isn't built-in (eg Firefox VPN). The act of having the user do something means that for a brief moment, they have to concentrate on the product. Consumers have this tendency to value things higher if they were involved in its success, such as when building flat-pack furniture.

The technical side is that while a VPN is indeed just a tube that transports packets securely to the VPN servers, the fact is that there are so many ways for this to go wrong. For example, leaking DNS requests is a way to throw the confidentiality guarantee* of a VPN out the window. As can Happy Eyeballs, where the same HTTP request is sent by both Legacy IP and by IPv6; if both aren't sent through the tunnel, confidentiality is lost.

To deal with this, the client can implement mitigations, such as setting a different DNS nameserver, as well as the (IMO exceedingly inappropriate) measure of disability IPv6 outright. These are not functions which the built-in VPN client in the OS would necessarily do, although some OS network managers genuinely will do a good job. But even more important than applying mitigations is to check for leaks! The client app can run periodic tests to make sure DNS or IP packets are always going down the tunnel, such as by checking destinations that only exist through the tunnel. Failure to pass this test should throw up huge warnings that the user's confidentiality may be imperiled. This is table stakes for a retail VPN service in 2026.

Finally, UI/UX for a VPN requires that the whole thing be easy: users want to browse the web, download ... uh... Linux ISOs, and go about their life with a VPN that Just Works (tm). Most people do not want to copy a Wireguard config into the OS using a terminal. A VPN service should have broad appeal, since the ~~fear mongering~~ advertising suggests it's a product that everyone online should use.

At bottom, we can say that "retail VPNs" really do need a client app. But for technically minded folks, a Wireguard config would be enough, because the endpoints would also be configured to route solely down the tunnel. Or even use an isolated netif, in the case of Linux namespaces, which is IMO quite clever.

Open-source VPN clients do not implement the most important feature - a monthly reminder to pay your bill. Well, and dumbing down the technical UI to one big green button, so even dumbest users would not have trouble with it.

a lot of them do offers wireguard/openvpn config files as an alternative to their clients, but those offers more features such as speed tests, quickly switching between profiles (I don't really want tens of different VPN profiles on my network manager), some extra settings easily reachable such as a network killswitch if you get disconnected etc

With some VPNs (Mullvad and NordVPN to name two) you can use your own clients by downloading lists of VPN relays and whatever authentication credentials the protocol uses. Though if you use the official client, it often has options beyond the protocol, such as selecting multiple hops (i.e. entering at one relay and exiting from another), disguising your traffic as another protocol (useful if you’re somewhere where VPN traffic is blocked) or padding traffic to a constant size to prevent profiling (i.e. by comparing to known video streams).

• The way to the provider does account auth varies.
• The API for getting e.g. server list info varies.
• Configuration generation varies.
• Implementation choices for the VPN protocols varies (e.g. which user-space wireguard implementation to use if the kernel one is not usable for some reason).
• Some features would require some scripting/light programming if not implemented by the provider. Not only is that asking for a lot, but errors here can be catastrophic.
• ...etc

All that, and we didn't even talk about user experience 😉.

Having said all that, if you're not using a service that offers configuration generation, which allows you to use your own clients, you're doing it wrong.

I use one of the services from your list. And beyond private key generation, I do everything with simple scripts on desktop (or using "protocol" clients on mobile). This is trivial since the server list with its addresses and public keys is publicly available as JSON, even without auth. So putting that info and my private key(s) together, I can actually generate all the configs I want myself with ease.

But that's just me. And providers would go broke if they only catered to the likes of me.

You could make the same case for a browser, an email client, a graphics or video editor, etc. The UI is an interface to basic core processes that are usually the same that all have, with some extras on the top for uniqueness and features that might be more appealing than other UIs.

Being in full control of their own app, without conflict of interest from a competitor. Also they might use different programming languages, optimize for different environments they care about. And also to differentiate themselves from the competitor, to have an identity. Similar to how game consoles play the same games, but have their own identity behind it. And they want to sell their own subscription, so they only support and promote their own.

Just to name a few things that come to my mind. I don't use all those different tools, so I maybe wrong.