I also do not support the BIP 148 UASF, and I'd like to add to the points that Greg has already raised in this thread.
BIP 148 would introduce a new consensus rule that softforks out non-segwit signalling blocks in some time period. I reject this consensus rule as both arbitrary and needlessly disruptive. Bitcoin's primary purpose is to reach consensus on the state of a shared ledger, and even though I think the Bitcoin network ought to adopt segwit, I don't think that concern trumps the goal of not splitting the network.
Many BIP 148 advocates seem to start with the assumption that segwit already has a lot of support, and suggest that BIP 148 does as well. However I don't think it's fair or correct to separate the activation proposal for segwit from the rest of the segwit proposal. The deployment parameters for segwit are consensus-critical; assuming that some other deployment has consensus because it would result in the rest of the segwit proposal activating is an unjustified leap.
Even if there were no feasible alternate segwit deployment method available to us, I would hesitate to recommend that the network adopt a potentially consensus-splitting approach, even though I firmly believe that the ideas behind segwit are fundamentally good ones. But fortunately that is not the situation we are in; we have substantially less disruptive methods available to us to activate it, even if the current BIP 9 deployment were to fail -- such as another BIP 9 deployment in the future, or perhaps a BIP 149 deployment.
If we do pursue a "user-activated" deployment of segwit, I'd recommend that we do so in a more careful way than BIP 148 or 149 currently suggest, which as I understand would otherwise make very few changes to the current implementation. However, due to the BIP 9 activation assumption, the Bitcoin Core 0.13.1 - 0.14.0 segwit implementation largely lumps together the idea that miners would both enforce the rules and mine segwit blocks. However, we can separate these concerns, as we started to do in the Bitcoin Core 0.14.1 release, where mining segwit blocks is not required in order to generally mine or signal for segwit in the software. And we can go further still: without too much work, we could make further improvements to accommodate miners who, for whatever reason, don't want to upgrade their systems, such as by improving block relay from pre-segwit peers [1], or optimizing transaction selection for miners who are willing to enforce the segwit rules but haven't upgraded their systems to mine segwit blocks [2].
If we would seek to activate a soft-fork with less clear miner signaling (such as BIP 149), then I think such improvements are warranted to minimize network disruption. In general, we should not seek to censor hashpower on the network unless we have a very important reason for doing so. While the issues here are nuanced, if I were to evaluate the BIP 148 soft-fork proposal on the spectrum of "censorship attack on Bitcoin" to "benign protocol upgrade", BIP 148 strikes me as closer to the former than the latter. There is simply no need here to orphan these non-signalling blocks that could otherwise be used to secure the network.
To go further: I think BIP 148 is ill-conceived even for achieving its own presumed goals -- the motivation for adding a consensus rule that applies to the version bits on blocks is surely for the effect such bits have on older software, such as Bitcoin Core releases 0.13.1 and later. Yet in trying to bring those implementations along as segwit-enforcing software, BIP 148 would risk forking from such clients in the short term! If one really cared about maintaining consensus with older, segwit-enabled software, it would make far more sense to seek segwit activation in a way that didn't fork from them (such as BIP 149, or a new BIP 9 deployment after this one times out). And if one doesn't care about such consensus, then it'd be far simpler to just set (e.g.) August 1 as the flag day activation of segwit, and not play these contortionist games with block version bits, which carry no useful or intrinsic meaning. Either of these two approaches should have the advantage of reduced fork risk, compared with BIP 148.
Of course, everyone is free to run the software of their choosing. I write this to both generally convey my opposition to a careless proposal, which I believe represents a way of thinking that is detrimental to Bitcoin's long run success, and specifically explain why I oppose inclusion of this proposal in the Bitcoin Core implementation [3]. The Bitcoin Core project hasn't been, and shouldn't be, careless in deploying consensus changes. Instead, I think the Bitcoin Core project ought to stand up for the best practices that our community has learned about how to deploy such changes (specifically for minimizing chain-split risk when deploying a soft fork!), and I think we should all avoid adoption or encouragement of practices that would depart from the high standards we are capable of achieving.
--Suhas Daftuar