Q: What's wrong with "dummy" transactions to make up the difference?
A: Nothing, as long as 2 years from now you're OK with wasting 2-8GB of HDD space just because some idiot decided there should be a "minimum sized block" and you're in favor of being in direct opposition to scaling.
Over 1M is just for first block, meant as reorg (anti-wipeout) protection.
Q: What's wrong with waiting until the mempool supports the new block size minimum?
A: Let's suppose segwit reduces weight count by 30%. That means that it takes 30% more transactions to fill 1MB of space, compared to pre-segwit. That, also, means that when there aren't enough transactions to fill 1 block, that block will take 30% longer to fill and confirm. That further means that there would be 0 transactions left to start the next block and each successive block would take exponentially longer. This all means that, if segwit actually works, there could be times where there are 1 hour block times and 3 hours to confirm 6 blocks could become a regular thing. This is the diametric opposition to scaling.
Again, over 1M is just for the first block. If it happens by chance mempool is empty at that time, it usually fills to over 1M within 20 minutes.
Anyway, I hope the SegWit2x activation wont get rushed. It would be prefferable if the code is improved to automatically create first block over 1M even when the mempool is empty. It also means more testing, so activation after Aug 1, but with advantage SegWit2x could be activated only when there is demand for it and most full nodes are SegWit2x compatible to ensure its success. So it has many advantages to dont rush it just to meet the insignificant Aug 1 fork from few people.