I did some studying about the way that Azure handles the default routing between the multiple address spaces of a VNET. Refer to "Network" heading under the Default Routes section in this article for more information
" Routes traffic between address ranges within the address space of a virtual network. Azure creates a route with an address prefix that corresponds to each address range defined within the address space of a virtual network. If the virtual network address space has multiple address ranges defined, Azure creates an individual route for each address range"
So when multiple address spaces are configured for a VNET, Azure automatically adds a default route for each of the address spaces. You can check this by deploying a VM in one of the Vnet's subnet and check the "effective routes" from its Nic's properties. You would find default routes to the below stated with "Virtual Network" as the next hop.
a) every other address space in the same VNET
b) every other address space of the peered or connected VNETS
The only tricky part is that when we configure the address pool for P2S connections, Azure creates and manages this as an additional address space of the Vnet. This would not be seen in the portal though. I did not try to check the same with PowerShell though.
When the client connects to the VPN, it receives an IP from the configured address pool. Since Azure manages the routing between the multiple address ranges the client would be able to access the VM's in the same hub VNET and the peered VNETS directly (without any gateway or involving multiple hops)
One quick test that I did to confirm my understanding -
a) Configured the P2S client address pool as stated in the ques - 172.16.100.0/24
b) Now tried to add a conflicting address space as a second one in the Hub Vnet - 172.16.0.0/16
This operation resulted in an error because of the conflict of address spaces.
One other post that talks about the working of routing when multiple address spaces (a more complicated one though)