Not visible in the link, but it looks as if this was published at ISCA, which explains why it doesn’t appear to have been reviewed by any security experts. If I had been a reviewer, my main objections would have been:
I’ve been on programme committees that have rejected better hardware security papers than this. It’s representative of a common set of things that really bug me in academic work: The rush to submit a paper and the lack of RSE funding in grants means that they weren’t able to do the engineering work that’s required to properly evaluate it with a large corpus of real-world C/C++ code and a proper red team, so they never hit any of the corner cases that break this kind of scheme. This composes with our field’s refusal to publish negative results means that they have no incentive to take it to that level because if they find problems then they can’t publish. I would love to read a paper that had done a proper analysis of this and shown why it didn’t work, but ISCA would never accept that paper.
Oh, and on a personal note, their evaluation of CHERI appears to be based on the ISCA paper from 2014 and not any of the follow-on work (hint: capabilities haven’t been 256 bits in CHERI since around 2016).