This is all great and wonderful, except for one thing - the RIR allocation boundaries were never really meant to be used as "official" filtering prefix length limits. I certainly support Verio's right to filter on whichever boundaries make business sense to them. However, there is no denying that they have long been on the conservative side of filtering, and that this has caused problems for their peer's customers. Their policy causes a certain amount of difficulty for smaller multihomers, who may not have a RIR allocation.
It only causes problems, under the majority of circumstances, when people fail to announce their largest aggregate. If they announce their RIR provided aggregates, then there is no problem. The RIRs provide lists of their smallest allocation sizes, which facilitates locking into a certain expected prefix-length. While it may not be "official", it is certainly a good cross-pollination of data, which is probably why the RIRs send notifications here when they change their allocation policies. Everyone I've seen who bases their filters off of RIR allocation guidelines does so slightly more loosely than the guidelines themselves. IMHO, this is better than simply drawing a one-size-fits-all line in the sand. If you permit /24 across the board, you may as well not filter, as that is where the greatest amount of crap is (according to what I've seen). If you permit /23 across the board, you'll filter out those folks living in chunks where the RIRs have assigned /24s leading to blackholes of the cluefull. As such, some correspondence to RIR policy is advantageous in fine-tuning the filtering to make sure you don't filter out legitimate folks for which there is no greater aggregate, while filtering out those who (un)intentionally abuse BGP. If the RIRs were to begin allocating space from specially designated "multihomer" blocks, for such small multihomers, I don't see that those who presently filter based upon RIR policy would have a problem. Also, the small multihomer wouldn't have a problem, and the present degree of dishonesty expressed to get "large PI blocks" would hopefully subside. I believe RIPE is presently doing just this type of thing. However, RIR policy is up to the RIRs. The only drawback I've seen is the unfortunate case where a small multihomer can be partitioned away when their connectivity to the provider who allocated them some PA space goes away. However, there are means through which the small multihomer may use to rectify that situation (which don't involve dishonesty). RFC2260 is one such way. Again, if there were a range dedicated purely to the small multihomer, the filters could be updated to account for that policy, and there would be no issue even outside steady-state. Between permitting small PI blocks to small multihomers, and slightly looser than RIR guidelines for the remainder, there would be few innocent victims, there would still be controls over folks attempting to use BGP to offset their TE, and well the clueless would remain clueless, but there's not much you can do about them.
Currently, RIR's will issue an AS and will allow the issuance of a /24 to a multihomed enterprise, simply on the basis of being multihomed. From this point of view, it's easy to make the case that the proper "RIR-approved" boundary for prefix filtering should be at the /24 level. At any rate, Verio has been slowly liberalizing their filtering policy, and bring it into line with the rest of the industry.
If the RIR is issuing /24s, then they denote such on their minimum allocation lists, allowing providers to accept /24s from such blocks.