The traditional way to do a VPN is that your VPN endpoint ('server') is the single point of entry for all traffic from VPN clients. When a VPN client talks to anything on your secured networks, it goes through the endpoint. In what I'm calling a mesh-capable VPN, you can have multiple VPN endpoints, each of them providing access to a different network area or service. Because it's one VPN, you still have a single unified client identity and authentication and a single on/off button for the VPN connection on clients.

(WireGuard is one of the technologies that can be used to implement a mesh-capable VPN. WireGuard can be used to build a full peer to peer mesh, not just a VPN-shaped one.)

A standard, non-mesh VPN is probably going to be simpler to set up and it gives you a single point of control and monitoring over all network traffic from VPN clients. Despite that, I think that mesh-capable VPNs have some real points of appeal. The big one is that you don't have to move all of your VPN traffic through a single endpoint. Instead you can distribute the load of the traffic across multiple endpoints, going right down to individual servers for particular services. As an additional benefit, this reduces the blast radius of a given VPN endpoint failing, especially if you give critical services their own on-machine VPN endpoints so that if the service is up, people can reach it over the VPN.

This is probably not a big concern if your VPN isn't heavily or widely used. It becomes much more important if you expect many people to access most of your services and resources over your VPN, for example because you've decided to make your VPN your primary point of Multi-Factor Authentication (so that people can MFA once to the VPN and then be set for access to arbitrary internal services). If you're expecting hundreds of people to send significant traffic through your VPN to heavily used services, you're normally looking at a pretty beefy VPN server setup. If you can use a mesh-capable VPN to offload that traffic to multiple endpoints, you can reduce your server needs. If you can push important, heavy traffic down to the individual servers involved, this can take your nominal 'VPN endpoint' mostly out of the picture except for any initial authentication it needs to be involved in.

Another feature of a mesh-capable VPN is that the VPN endpoints don't even have to all be on the same network. For example, if you split endpoints between internal and external traffic, you could put the external traffic VPN endpoint in a place that's outside of your regular network perimeter (and so isn't contending for perimeter bandwidth and firewall capacity). In some environments you wouldn't care very much about external traffic and might not even support it, but in our environment we need to let people use our IPs for their outgoing traffic if they want to.

A mesh-capable VPN can also be used for additional tricks if you can restrict access to parts of the mesh based on people's identities. This can be useful to screen access to services that have their own authentication, or to add authentication and access restrictions to services that are otherwise open (or at least have uncomfortably low bars on their 'authentication', and perhaps you don't trust their security). If you can easily extract identification information from the VPN's mesh, you could even delegate authentication to the VPN itself rather than force people to re-authenticate to services.

(In theory this can be done with a normal VPN endpoint too, but in practice there are various issues, including a trust issue where everyone else has to count on the VPN endpoint always assigning the right IP to the right person and doing the access restrictions right. In practice people will likely be more comfortable with a bunch of separate little VPNs; there's the general use one, the staff one, the one a few people can use to get access to the subnet of laboratory equipment that has never really heard of 'access control', and so on.)