dApp developers don't really need to manage max-transaction-time. This is not the way to plan your dApp.
Your share of CPU is determined by your share of the EOS tokens you delegate towards CPU as a percent of total CPU.
In case of over capacity, you will enjoy additional CPU processing power.
Regarding the unpredictable factors:
21 different CPUs, they take turns processing transactions in a round robin method so you can take the average of the 21 top BPs. Yes this list is dynamic and changes with votes changing. You can Add some of the top stand by block producers, perhaps this will improve the estimate. Also, consider that Block Producers will upgrade their hardware and the EOSIO software will also be improved. There are even plans to create custom CPUs with optimizations for EOSIO.
max-transaction-time can be tweaked by each block producer. There are reasonable default values for all parameters and you can assume that most will just settle with those. A block producer that changes this too much risks dropping transactions that other block producers will be able to process. This will make it a lower quality block producer and voting will be reduced for it.
No virtual memory is allowed. This is why RAM is such an interesting topic for debate.