Thanks for commenting, Mike. There is some confusion that Bitcoin Unlimited (at least the version that everyone is talking about right now) doesn't have a block size limit. The default block size limit is actually 16 MB for block acceptance (and 1 MB for block creation). However, node operators can adjust these limit as they see fit. The "unlimited" is in reference to unlimited choice.
Big attack blocks would be orphaned. The reason we added the "excessive block logic" was to automatically deal with a (very unlikely IMO) network split attack.
So who adjusts the default and how do you ensure everyone adjusts it simultaneously?
BIP101/XT works the way it does for a reason. I don't think making it a command line flag makes sense. Everyone still has to change their setting simultaneously. If you fix that so changing the command line flag casts a vote for a new size you end up reinventing something like BIP100.
It doesn't sound like everyone has to adjust simultaneously. If you find you're generating an unacceptably high number of orphans, you can reduce your block creation limit. Otherwise, EVOP it up until you're satisfied. Or, check some other statistical data about current network acceptance before setting your own limit.
With Core and XT everyone needs the same max block limit. BU is different in that only the whole network possesses the attribute of a gently dynamic max block limit, while each individual node has an approximation, or even a value which is a lot smaller or larger. It doesn't matter, except that nodes with a too small value will frequently have the latest blocks "on probation" waiting for them to reach an acceptance depth, number of confirmations.