After years of no compromise on increasing the block size cap, and failing to deliver its own products on time (SegWit, Lightning, etc.), Blockstream and Core developers are now calling those who wish to prioritize on-chain scaling as "blockers" who are obstructing progress.

This could not be further from the truth.

Firstly, not voting for the SegWit soft-fork is a technical decision that some parties have reached.

Berating those who express a different technical opinion than you - using the consensus mechanism put in place by BIP9 -- frankly reduces the credibility of those who engage in such an attitude.

Secondly, they are not voting against SegWit because they think it contains nothing good whatsoever. Endless discussions have been conducted on various subs, and the objections to the current SegWit soft-fork proposal are many and varied. But there is also recognition of certain good aspects.

However, there is major disagreement about what's urgently needed, which makes this soft-fork proposal very contentious and unlikely to quickly acquire the consensus required by BIP9.

While there are several possible outcomes, stagnation is unlikely to be one of them. Why? Because the pressure to do something is rising all the time, and efforts are well advanced on various fronts to provide alternative solutions to the problems that SegWit solves.

If the network were to move to Bitcoin Unlimited's (BU) model of regulating the block size cap, that problem would be solved - we would not need to have the conversation about the cap again in a year or two, unlike with SegWit. While it's true that another hardfork would be needed to solve worst-case complexity of signature hashing etc. it is worth bearing in mind that this is true even on SegWit for traditional (non-witness) transactions. And the emergent consensus feature of BU ensures that the node operators (miners relays) can regulate block sizes and the cap in a safe way in the meantime (starting out low and slowly adjusting higher to stay ahead of demand).

Flexible Transactions, which is already in testing on a separate testnet, would give a more extensible transaction format and fix transaction malleability and inclusion of amount in signature, like SegWit. There are also possible hashing improvements that can combat double spending, which would reduce the risk of 0-conf transactions and so contribute to making Bitcoin more user-friendly.

So don't be fooled by those who want to make you believe there are no better alternatives, and who say that those not voting for SegWit are doing so out of spite, lack of understanding etc.

They are not voting for SegWit because Bitcoin requires more transactions to be actually valuable and successful. SegWit in its current Core implementation falls far short in that respect, and requires end-user adoption for significant capacity benefits to materialize.