Why am I able to connect from 10.8.0.* to 192.168.0.* and from 10.8.0.* to 10.8.0., but not the other way around (192.168.0. to 10.8.0.*)?
You're able to connect from 10.8.0.* to 192.168.0.* because
the OpenVPN server is directly connected to both networks, and therefore automatically has "direct" or "local subnet" routes to both of them;
the OpenVPN server is most likely set up to perform NAT for packets in the VPN→LAN direction, essentially hiding the 10.8.0.* network.
When you make a connection from VPN to LAN, your LAN hosts think they're talking to the VPN server itself – to its 192.168.0.x address specifically, which they already know how to reach, and therefore remain able to reply.
(Just like Internet hosts are able to reply to your PC – they think they're talking to your router's public IP.)
In short, NAT "papers over" the lack of end-to-end routability, which is why most "Pi home VPN" tutorials tend to include it. (That, and many home routers have their routing table locked down with no manual configuration possible...)
I tried adding a route on the host machine as directed by this answer, but got this error:
PS C:\Windows\system32> route ADD 10.8.0.10 MASK 255.255.255.0 10.8.0.1
The route addition failed: The parameter is incorrect.
The first of two problems with this is that you can't add a route "via 10.8.0.1", because… you don't have a route to 10.8.0.1 yet.
(The 'default' route that you have, even if it matches all addresses, is insufficient – for one, it leads the wrong way; that's why you're adding the custom route in the first place – and more importantly, it's not a "direct" route, it's already a "gateway" route on its own, and you can't route through a gateway that's behind another gateway.)
The general rule is that a gateway address (the 'via' address) must be reachable directly, which roughly means it must be from within the PC's own subnet. If your computer is in the 192.168.0.x/24 subnet, then the 'gateway' address must be the OpenVPN server's 192.168.0.x address as well.
Or in another way of describing it, the 'gateway' address must be the address of the Pi's interface that's facing the PC (usually eth0 or wlan0), not the one that's facing away from it.
(There are exceptions to all of this, but that's how it works in most regular cases.)
I also tried the local IPs (wlan0 and eth0) of the VPN server for the final argument (in place of 10.8.0.1 and got the same result
The second problem with your route is that the "destination" (10.8.0.10) contradicts the "mask" (255.255.255.0). That is, the destination you specified says that you want to route a specific host, while the netmask you specified says that you want to route the entire 10.80.0.x network.
If you want to route the entire 10.8.0.x network, then specify the all-zeros address of that network (what's often called the "network address") as the destination. In your case that's 10.8.0.0.
If you want to route a single address, then adjust the mask to only cover a single address – use 255.255.255.255 or 10.8.0.10/32.
Because this is a 'via' route, it doesn't care at all what the actual subnet size is (only the final router needs to know that), so the mask isn't straight up copied from the subnet mask; it's adjusted to suit the needs.
I also tried various combinations on the client machine, all with the same error.
From the client machine, it would likely be 192.168.0.0 mask 255.255.255.0 10.8.0.1, but there's some additional complexity because most OpenVPN setups use 'tun' mode which doesn't actually support routing 'via' any specific gateway – you can only route 'via' the tunnel as a whole (using the iface parameter). On top of that, such a mode is not quite a built-in concept in Windows and may behave differently depending on which of 3 different Windows tunnel drivers (TAP, Wintun, DCO) is being used by the OpenVPN client at that moment.
In any case, it sounds like the client machine already receives a route for 192.168.0.x due to the OpenVPN server pushing it as part of the connection handshake – your server likely has a push "route ..." option and the client .ovpn configuration files have a pull option (or something that implies it) – so manual tweaking there is likely not necessary.
