RFC1918 and VPN becomes non-scalable fast when you connect to lots of different organizations - it doesn't take long before two organizations you connect to both want to use 172.16.0.x/24 or 10.0.0.x/24 or 192.168.0.0/24, or similar). The same logic goes for VPN clients - if one end is potentially using RFC1918, the other end better not use it. Since you can usually only control one end of the VPN for road-warrior VPN, it's best to make that end not use RFC1918. Otherwise you may find you need to route 192.168.x.y, but that just so happens to be the user's default gateway, name server, printer, or other key device. Of course having another set of NAT addresses for CGN will solve everything (yes, that's sarcastic, but I can predict how they'll be used to "solve" this type of problem).
Just because "it usually works" doesn't mean using RFC1918 addresses for left and/or right subnets in a VPN is a good idea.
My workplace solves this by just NATing again. It isn't the best solution but it does work. Put aside a 10.0.0.0/16 and whenever you have a NATed network you want to connect a VPN to on the edge just static NAT the addresses to make them unique again. Their 172.16.x.x becomes your 10.2.x.x. I dunno about 'not scalable'. I guess if your connecting to thousands of networks it won't work well, but for a a few hundred it works well enough. I'm sorry you don't like it, and I know IPv6 will wash all this away soon enough, but where I'm working we have no plans to implement IPv6, or require our vendors/partners to readdress their networks to get a VPN up.