Strict URPF cannot be applied to any customer that might be multihomed, which rules out any BGP customer or peer.

The reason is that multi-homed networks are not required to, and often do not advertise the same routes to all of their BGP peers. This may be done for routing policy purposes, traffic engineering, or simply to mitigate a temporary performance problem/outage with one of your transit providers/peers.

This means that strict URPF has to be deployed on the many networks that are close to statically routed end users. However, even statically routed customers could be multihomed and send traffic asymmetrically. This is not common but could cause headaches for support - even if you make an exception it could get accidentally overridden in the future.

On my networks (data center/hosting) we configure strict URPF on statically routed customers by default but not for BGP customers.

How are transit providers supposed to do source filtering on each other?

Where Centurylink peers with Verizon, where is Centurylink supposed to get that source filtering table from? What if a Centurylink customer (who has their own AS) dumps them for Verizon?

This problem repeats with the Tier-2 transit carriers, and Tier-3, and so on.

You're expecting an exponential number of source filter updates every time somebody moves their route announcement from one provider to another. This does not scale.

Source filtering can only really be implemented when you're taking traffic from a network for which you are the only uplink. If El Badguy (tm) is on one of these networks there really isn't a practical place to source-filter them.

At least for connectionless protocols, just do harsh source filtering and blackhole packets that don't comply... that's possible these days, right?

Give the peers some time; 3 months should seem enough for all that can't explain why they need a 3 month extension. And yes, this of course relies on assumed symmetric paths (even if asymmetric ones may get chosen after prioritizing).