IRR already contains all the data. Cryptographically signing it can't increase the rate at which people will use it (one could argue throwing crypto into the mix decreases adoption). RPKI is just crypto nerds trying to math their way in to a human and financial problem.
Until routing vendors start shipping sane IRR based route filtering in default configs and make it hard to turn off, this is something we have to deal with.
> RPKI is just crypto nerds trying to math their way in to a human and financial problem.
Well-designed cryptography lets us tilt the odds violently on these human problems so as to give us greater confidence to take action when appropriate.
If you say maybe your technician typed 185.42.16.0 when they meant to type 158.42.61.0, that they uploaded last month's data instead of this month's, they wired a patch incorrectly - these are not implausible accidents. But cryptographically signed records don't happen by accident. You can't "typo" a 1-in-billions-of-billions chance.
IRR contains data - question is can you trust it? RIPE has cleaned up their stuff, sure, but the rest of the IRRs out there haven't. Next question is which IRR once you get past the RIRs? AltDB? There's a few out there. Lots of crap objects and proxy registration, that said there are a lot more things in IRR than ROAs out there.
I do agree with you that routing vendors have made this difficult to easily ingest prefix list data for easy import into inbound filters. There have been NANOG presos from last decade showing the performance hit when you try to do this at scale. It is much easier to enable RPKI OV than it is to build a robust IRR filtering system.
Until routing vendors start shipping sane IRR based route filtering in default configs and make it hard to turn off, this is something we have to deal with.