This does appear to be an IP subnet routing question. And you may (or do?) understand some of the following.
The usual approach involves rationalizing the network and particularly subnets and DHCP server assignments across the organization, and to use IP routers and (potentially) static routes between the "hunks" of the networks; the subnets.
If you don't have a whole lot of network traffic, then stuffing everything into the same /22 is simple and will work fine.
However, a /22 can be a whole lot of hosts for one segment, and can easily saturate any existing GbE-class backbone(s) as those hosts get chatty. You've also got the usual Bonjour and other multicast traffic rattling around within that whole subnet (Bonjour doesn't pass beyond an IP router by default), and propagating multocast announcements and related traffic through the whole network might not be entirely appropriate, or might be confusing to users. Using smaller subnet hunks and routers, the network traffic can be more effectively partitioned, with less traffic on the backbone(s).
If you decide to partition the network, it's common to partition based either on network topology or on organizational function, and variously on both. You might have a four-wing building with north, south, east and west networks because of the wiring - or New York, London, Singapore and Sydney based on location - or you might have an overlaid Student and Faculty or Operations and Finance networks - and set the routing up accordingly. The former design to partition the network traffic on (or off of) the physical links, while the latter partitions the information. And it's quite feasible to combine the two schemes.
I'd also likely migrate the VPN servers off of the OS X systems and over to the network perimeter (usually at or via a gateway), as implementing a VPN server at the network edge is usual easier to manage in my experience, and particularly when NAT passthrough is involved. (And OS X makes for a comparatively expensive and under-performing IP router, too.)