It's surprising to see there's a lot of support for a UASF in some circles. It shows that a lot of the proponents for SWSF are blindly putting their trust into a centralised planner when the purpose of Bitcoin is to be trustless and decentralised. The irony is astonishing.

Also to note, nobody on the bitcoin-dev mailing list has shown support for the idea yet, and the general consensus seems to agree with Vitalik's tweet.

Theymos on the idea:

Another consideration is that if miners are expected to keep producing very long invalid chains under the new rules, then this sort of softfork has almost exactly the same costs as a hardfork. So if this is considered a likely outcome, then it'd may be better to just hardfork and make some other useful hardfork changes at the same time.

Luke Jr on the idea:

failure to validate a softfork is similar in some respects to a hardfork, but with one critical difference: the default behaviour of old nodes will be to follow the chain with the most-work that was valid under the pre-softfork rules. This actually inverts the benefit of the softfork over a hardfork, and makes a softfork deployed in such a manner de facto behave as if it had been a hardfork, IF someone ever mines a single malicious block.

I'm yet to see any support for the idea outside of Twitter warriors and Charlie Lee.

Let's hope this is the realisation of talks to HF to bigger blocks (preferably emergent consensus driven) and a cleaner SegWit implementation, and to finally ending the impasse.