For people reading along, Peter routinely says "we" will do things that he hasn't built any kind of consensus for at all, so I'd take things he writes with a pinch of salt.
Funny that, I seem to remember Pieter Wuille, Matt Corallo and others arguing with Peter on IRC about P2SH, note how Peter's arguing against:
if it were up to me, P2SH would be the only supported way of doing transactions in the first place
sipa: agreed
sipa: lets make everything but p2sh non-standard in 0.9
or...maybe 1.0
sipa: It makes it a lot easier to do auditing in many cases, where OP_CHECKMULTISIG, for example, lets you easily see where funds are even when they're being semi-controlled by others, without requiring extensive communication.
http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/06/03#l7531211P2SH-only is also on the Bitcoin feature wishlist on the wiki, and Gregory Maxwell argued for it was well when he proposed P2SH^2. It'd probably just take some more child-porn related materials in the blockchain to get OP_CHECKMULTISIG disabled, remember that with it you can easily both insert data and make the txout spendable at the same time so that even if you decide you will blacklist txouts in response you are forced to blacklist spendable txouts and thus take peoples money. That is a much harder problem politically. Great fun could be had by someone creating time-locked announce-commit sacrifices spending those txouts in the future with large fees or to particular people. Do you really want to have a process by which we change the rules for how individual transactions can be spent by a central committee based on evidence that is illegal to examine, and thus illegal for the community at large to admit to auditing? Warning that P2SH and pay-to-script-hash (both are compatible with gmaxwells proposal) may one day be the only legal transaction types is a very reasonable thing to say.
It's what you write is what we need to take with a pinch of salt.
I don't have any intention of filtering script types in the bitcoinj implementation of the payment protocol. If a merchant wants to use an exotic script type then it's up to them to get it mined (that's why you can submit transactions directly). I also don't intend to make P2SH used by default, indeed, bitcoinj does not support P2SH transactions at all today and nobody has ever complained. So requiring P2SH transactions is a long way from happening, if it ever happens at all.
Unless you make stub transactions you will find your users getting their funds locked up because of merchants failing to get the transactions mined for whatever reason. For many merchants there isn't a strong incentive to get a transaction confirmed quickly because they either don't actually incur a cost immediately (shipping) or because anti-double-spend measures are working properly. At least with P2SH if miners do child-pays-for-parent the client can get the transaction mined that way regardless of what crazy scripts the merchant wants to use for txouts in their wallets.
As pointed out, it imposes "only" a 15% bloat on the block chain.
No, as Peter pointed out it is 1 byte more efficient than the pay-to-script-hash method used currently, a method that protects Bitcoin from an ECDSA compromise. The 15% comes from the theoretical minimum transaction size, which creates dangerous risks for Bitcoin as a whole.
Besides, since when did you care about blockchain bloat?