I don't think it is "mindless fear" to point to Ethereum's failed hard fork and point out that it permanently split the network. This caused significant losses for custodians---Coinbase lost ETC and still hasn't repaid their customers. BTC-E was replay attacked and lost all of their customers' ETC; they won't be repaying it. The results would have been disastrous if Kraken and Poloniex didn't have the foresight to ignore the Ethereum Foundation's advice to ignore ETC and not repay their customers their money. Replay attacks were commonplace, and many users lost money in trying to spend on only one chain or the other.
Seems like mindless fear to me, the replay attack has been fixed on all of the proposed Bitcoin forks, it is rather trivial to fix actually. The ethereum foundation purposely decided not to fix this particular issue, I thought that was a mistake. Splitting Bitcoin as a minority would not cause such problems at all, custodians also need to be more responsible in such a situation and take it into account. Some of those custodians simply just did not believe ETC would survive, now we know better.
That's not true. If Classic merges an update to change transaction format (not just add a new transaction format), it will be true for Classic. XT and Unlimited offer no replay protection. This is actually not just a technical issue---many that believe that a clean hard fork (one network) is possible don't want explicit replay protection because it promotes the idea that multiple blockchains will emerge. This was partially why Ethereum did not include replay protection in their fork; they simply assumed the original chain would die. The very idea of including replay protection in a fork is to make both networks viable (i.e. to enforce a network split). In the past, Gavin became quite upset at the suggestion that a hard fork could split the network---I'm curious about his thoughts on this.
I suppose that is why I now support splitting the chain, the alternative chain would simply have alternative clients that support it, solving the replay attack on both networks. I think that you are correct in thinking that a non controversial hard fork is no longer possible unless it is done through Core, who seem unlikely to increase the blocksize limit anytime soon. Therefore the only solution for people like myself who prefer that Bitcoin stays true to the original vision of Satoshi, is splitting the chain, after all Satoshi was a big blockist as well.

While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall. If Bitcoin catches on on a big scale, it may already be the case by that time. Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms. Whatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial.
Long before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification (section Cool to check for double spending, which only requires having the chain of block headers, or about 12KB per day. Only people trying to create new coins would need to run network nodes. At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware.
The eventual solution will be to not care how big it gets.
But for now, while its still small, its nice to keep it small so new users can get going faster. When I eventually implement client-only mode, that wont matter much anymore.
The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users.
The threshold can easily be changed in the future. We can decide to increase it when the time comes. It's a good idea to keep it lower as a circuit breaker and increase it as needed. If we hit the threshold now, it would almost certainly be some kind of flood and not actual use. Keeping the threshold lower would help limit the amount of wasted disk space in that event.
Part of the problem in Ethereum is the heavily centralized development under the Ethereum Foundation, which has no public review/consensus mechanism. Vitalik said "let's fork" so mining pool admins ignored their miners, client developers forked their clients by default (no user choice whatsoever) and the fork came from the top-down. This makes user consent very difficult to gauge. Even in this context, Ethereum could not successfully hard fork.
Ethereum presently has the same consensus mechanism as Bitcoin, users can choose to use Ethereum Classic instead, this is what gives people the freedom of choice, that is part of the consensus mechanism of Bitcoin as well and soon this will happen to the Bitcoin network as well.
The effects of splitting the Bitcoin network and increasing the supply of "bitcoins" across multiple blockchains could be far worse for Bitcoin's value proposition than a network split in Ethereum.
Splitting the network does not worsen Bitcoins value proposition, since the share of total Bitcoins remains the same across all chains for investors, which means it does not create any type of monetary inflation, it protects the value of investors. Furthermore because it is already relatively easy to do this with a small minority it should already be a part of Bitcoins value proposition, if you are not taking this feature into account you are not truly evaluating the value of Bitcoin, for me it actually improves the value proposition of Bitcoin since I perceive this feature as being a crucial part of the governance mechanism.
Within a particular network, there has not been inflation, but you need to consider public perception and a confused userbase deciding among multiple networks, each with a supply of 21 million BTC. Again, I wonder if you could point to the protocol documentation or description from the whitepaper that suggests that breaking the consensus rules are "a crucial part of the governance mechanism"? Like I said, go ahead and fork....just don't be surprised when no one refers to your fork as Bitcoin.
Exactly, a confused user base does not change the fact that investors are still protected under such a mechanism. Not everything is in the whitepaper, but the consequences and reality of the rules that exists are within the code and the world for all to see. Because this is possible, it should be considered as part of the design of Bitcoin itself and considered inevitable from happening, especially considering the nature of human behavior.