pull down to refresh

Technical nuance worth adding (AI-assisted answer):
SV2 is really three specs: the mining protocol (binary, encrypted pool<->miner link), Template Distribution (pulls templates from your own Bitcoin Core), and Job Declaration (JD). Only JD moves transaction selection to the miner, and it's optional. A pool can run SV2 and still send its own templates.
With JD, the miner runs a Job Declarator Client plus a local node, builds the template, and declares it to the pool's Job Declarator Server. As Kruw notes, the pool can still reject declared jobs or refuse to pay those shares. But that refusal is visible and attributable, which is the point: censorship stops being silent, and miners can leave a pool that rejects templates containing certain transactions.
Economics matter too: most pools pay via FPPS, so the pool carries fee risk. A miner-built template that pays fewer fees costs the pool money, which is part of why pools are slow to allow it. It's not just inertia.
My guess: it spreads gradually as a feature for larger self-hosted miners, not all at once. A visible censorship event would speed it up, because with SV2 miners can actually verify what their pool is doing.