As I feared, request on feedback for this specific BIP has devolved into a general debate about the merits of soft-forks versus hard-forks (versus semi-hard Kosher Free Range forks...).
I've replied to several people privately off-list to not waste people's time rehashing arguments that have been argued to death in the past.
I do want to briefly address all of the concerns that stem from "what if a significant fraction of hashpower (e.g. 25%) stick with the 1mb branch of the chain."
Proof of work cannot be spoofed. If there is very little (a few percent) of hashpower mining a minority chain, confirmations on that chain take orders of magnitude longer. I wrote about why the incentives are extremely strong for only the stronger branch to survive here:
... the debate about whether or not that is correct doesn't belong here in bitcoin-dev, in my humble opinion.
All of the security concerns I have seen flow from an assumption that significant hashpower continues on the weaker branch. The BIP that is under discussion assumes that analysis is correct. I have not seen any evidence that it is not correct; all experience with previous forks (of both Bitcoin and altcoins) is that the stronger branch survives and the weaker branch very quickly dies.
As for the argument that creating and testing a patch for Core would take longer than 28 days:
The glib answer is "people should just run Classic, then."
A less glib answer is it would be trivial to create a patch for Core that accepted a more proof-of-work chain with larger blocks, but refused to mine larger blocks.
That would be a trivial patch that would require very little testing (extensive testing of 8 and 20mb blocks has already been done), and perhaps would be the best compromise until we can agree on a permanent solution that eliminates the arbitrary, contentious limits.