It's nice that PDF security is getting a bit more attention, but there are a number of things that this approach will trash, for instance, I don't have high hopes for the accessibility of the resulting PDF. (edit: and needless to say, any software in your pipeline which does full interpretation of an untrusted file will itself become the target for attacks, so this is only a useful tool if it is run in an extremely restricted environment)

I for one have been looking a lot into PDF/A for security. PDF/A is really meant for archival, but as a side effect has disallowed an awful lot of weird PDF features which are a security nightmare and pdf readers tend to implement badly/buggily. PDF/A-1 for example, the strictest level, disallows JPEG2000, TIFF, JavaScript, PostScript, embedded files... (PDF/A-3, FWIW is essentially useless from this angle, because they decided to allow arbitrary embedded files, so a valid PDF/A-3 could have pretty much anything in it).

There now exists a good PDF/A validator (https://verapdf.org/) which can be used to ensure PDFs conform to the standard, but of course, won't fix them if they're not.

PDF/A has an interesting implementation detail however - compliant PDF readers are supposed to automatically "turn off" non-PDF/A features when they encounter a PDF which declares itself as a particular PDF/A variant (even if it then goes on to attempt to use non-compliant features), which would hopefully prevent dangerous sections from being decoded and avoid exploitation). Another interesting feature of PDF is its appendable nature, which might raise the possibility of being able to "declare" an arbitrary PDF as PDF/A by simply appending an extra section to it, hopefully rendering it less harmful (though possibly at the expense of it appearing to have missing content when rendered).