Not quite sure what you mean. All it can do is turn undefined behavior on an out-of-bounds reference into a segfault, but if that ends up turning an RCE vulnerability into something less severe, it's still an improvement -- at least from that perspective. The intent is for the hardware-checked bounds to be at very close to the declared bounds for arrays in source code, at least in cases most typically subject to buffer overlow; see https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-947.pdf
(And I'm not sure how the alternative fat-pointer proposal you mentioned does better. Searched that page for references to strlen, but didn't find much.)
Bounds for storage are known when it is allocated. CHERI puts those bounds into the pointers (which double in size so they can fit), and has the processor do the runtime checks at every dereference. So, same effect as the proposal you reference, AFAICS -- just without altered syntax.
(And I'm not sure how the alternative fat-pointer proposal you mentioned does better. Searched that page for references to strlen, but didn't find much.)