I prefer the policy based routing as it is more customizable. Having a centralized management means you have a one size fits "most" situation, which we know it never really fits "most". sometimes you may only need a centralized management, but there may be an instance where you need policy based routing. I would rather keep what we have. Option BI can't show you an example of a centralized management because I haven't written it. It would look the same as it currently does on each client page, except that the interface dropdown would list all different VPN clients instead of only WAN/VPN, and it would be on its own page.
DNS policy is unrelated to client routing, and remains configured on each individual client pages.
What functions would you lose?
I'm not rewriting the whole VPN client implementation, that was already done last year. Only routing, and policy-routing.
Changing which WAN interface the connection occurs within the VPN client itself wouldn't make sense, as it would potentially conflict with the actual Dual WAN routing configured by the router. Dual WAN routing is its own, separate thing.
Not possible. The only way to do so is through packet marking at the iptables level when marks could be applied based on the destination port, and that would stop working the instant you use hardware-acceleration for NAT.