UASF, as explained well by shaolinfry here, is a scheme that basically requires overwhelming support from the userbase of Bitcoin. For this reason, even though it's a soft fork, which is fundamentally safer than a hardfork, is a risky strategy. Why support it? Why not just let things lie, and accept that updating Bitcoin is hard and that isn't, by any means, an unambiguously bad thing?
The answer at a high level, is that miners are now fully convinced that they not only have a say in changes to Bitcoin, but the only say. And that is a disaster.
2 months from now, no UASF gained any traction, miners, led by Jihan Wu, celebrate this victory and enact a new fork. It doesn't matter if it's a soft or hard fork, but the former are easier to do. It could be something stupid and disruptive like only allow transactions that say "Jihan wu is great!" in an OP_RETURN (note: SF because rule restriction, so old nodes don't get kicked off the main chain; but still massively disruptive because disabling old node txs). Or more realistically it could be some kind of hard fork to move to "emergent consensus", where miners entirely control the size of blocks, or .. whatever. What's far more important to Jihan and his crew is to establish the precedent – we say what the main chain is, because we have the hashpower.
If we've given up on any ideas of user activation, we are completely powerless to stop it. And that goes as much for Roger Ver as it does for Greg Maxwell, users, developers, anybody. Hash power no longer just orders transactions – it sets all rules, full stop. Many will say "they won't try to force a block reward increase or huge fees, they'd be going against their real incentives" – of course, mostly true, at least today. But it can be much more subtle, to start with. Hashpower sets rules on covert asicboost, enabling monopoly. It sets rules that decide what kinds of transactions are allowed. Jihan may feel (and there's evidence that some miners do feel this) that privacy-enhancing upgrades are intolerable; to stay on the right side of governments, no kinds of easy mixing tech is allowed. No second layer (which is too good for privacy) payment channels allowed. Let's disable OP_CSV that's "complicated", "technical debt".
So is anything realistic without UASF coordination, or are we doomed?
Disabling covert asicboost does not disable asicboost, it only stops miners having a secret reason to prevent a protocol upgrade (whether they've done it or not in the past). Consider people on the fence, e.g. Brian Armstrong at Coinbase. Can he stand up in public and say "I am against only blocking a secret usage of asicboost, which incentivises miners to block protocol updates apart from any other reason, to the tune of $100 million"? On what planet could he say that with a straight face? And the same for any other economically important actor – even miners cannot; although, probably some will, by spouting some bullshit. For this specific case, I think we should be able to get everyone economically significant on board, if only they can be told the facts in a simple, straightforward way. However, if I am wrong about that, the entire Bitcoin project to me is right on the brink of failure. Bitcoin controlled by miners will be a very shitty Paypal, ultimately.
Counterargument – why is a "cabal" of "Core" devs any better than a cabal of miners?
Here we come to the heart of the matter – should there be anyone in charge of changes? If so, who?
My first response is – no one should be able to make any changes, period, ideally. This is a possible, ideal, future – and at least we're trending in that direction. Changes are very hard, and I suspect many super-bright people with slightly thin skin have been very upset about how hard it is to get consensus on their proposals (one reason for so much friction).
But that future is not here yet, so let's look at the past: Satoshi pushed changes and told the miners to upgrade, end of story. Now we have hundreds of developers, with a much smaller number having the most influence. We use an open source governance process, where people gain influence via valued contribution over a long time, and even when they have influence, there are thousands of eyes on their proposed updates.
This governance model isn't perfect, because it involves people. It ought to work fine mostly for low-level technical changes. As a somewhat tech-savvy user, rather than contributor, I'm happy to let those who've proved themselves make the technical decisions, but with the understanding that the project has huge inertia, and that not every decision will be perfect. It's hubris to think you deserve your opinion on technical topics to be heard when you haven't put in the hours on the details of the code.
So while trivial changes to the code either don't happen, or don't cause contention anyway, some quite profound changes, over a period of time, still gain traction today, despite the aforementioned inertia – and segwit is by far the most important one recently, because it fixes a bug in the design of Bitcoin. Make no mistake, segwit is a huge deal – not because it increases the block size, that's a compromise really, but because it finally fixes a bug that will allow people to write code without touching the consensus layer, that enables real innovation; Lightning is the standout illustration of this, but there'll probably be others. Because of this bugfix nature, enabling innovation, segwit might be the last such big change that's even needed. So in this sense, we might actually fall at the last hurdle.