Many (most?) VPN mechanisms don't entirely remove access to the other routes from apps that manually request them, so even if an app isn't able to use something akin to "location services" on your device it might still easily be able to get access to your other IP addresses by sending requests with sockets manually bound to specific interfaces, and even might choose to lower the priority of information learned using interfaces that are clearly tunnel devices instead of network cards.
Also known as split tunnel, this can be used by corporate VPN solutions to lower the amount of network traffic entering a data center (so you don’t overload your undersized pipes)
No, I don't mean that. That's when you purposefully set your routing table to split some traffic to different paths. The premise here is that even if all of your traffic is supposedly going over a VPN, an app can often opt out of that and do whatever it wants.
I thought the complaint was that the browser was figuring it out directly and then exposing it, such as via the browser's location API, not that the website was figuring it out using non-location network mechanisms provided by the browser.
(FWIW, a website that is given media recording privileges can definitely do that, though, using WebRTC. If you don't have that privilege then you can still use the WebRTC API but it doesn't return alternative candidates. But I also don't think that is what they meant.)
