Some updates here targeted at the valuable suggestions from @albertov19:
The issue of having multiple system chains that rely on DOT as a reserve is still a problem, tho, as parachains typically see only 1 reserve chain.
With the “Minimal Relay” migration of balances to Asset Hub, Asset Hub becomes the main DOT reserve. Parachains can also use it as the only reserve and simply route DOT XCM transfers through Asset Hub.
possibly doing asset transfers and transacting within a single XCM program
This will be possible in XCMv5 with RFC#122 
I feel that Polkadot is missing big on exploiting (in the good sense) computed origins.
I agree! As discussed here, all system chains already have unified location → account conversion, all the using the same HashedDescription<AccountId, DescribeFamily<DescribeAllTerminal>> converter.
It’s now simply a matter of the ecosystem chains aligning on this too. I expect the chains that rely on cross-chain user actions have already or will quickly align. The others… well they probably don’t care or need it.
I think the
PolkadotXCMpallet needs to keep improving to abstract more of the complexities of XCM. For example, having functions that wrap some simple XCM programs like XCM Channel Open, Accept, Close, and remote transact.
I actually envision leaner XCM pallets and richer TS/JS/Rust libraries and tools that build/expose these any many more flavors of XCM programs.
System chains now allow anyone to pallet_xcm::execute() and I am encouraging the rest of the ecosystem to do the same. This means we can build these useful XCM programs offchain, vend them as libraries and they can be used on any chain.
Developing these off-chain allows orders of magnitude improvements on: developers who could contribute, number of helpful programs provided, iteration speed, etc.