Meh, it's subjective but I'd argue that's a bad idea. A 404 isn't exactly a heavy request; your origin should be able to handle plenty of those. The whole point of CDNs is to serve fat assets (images, videos, js libraries sometimes) not patch holes in your site or bandaid your raspberry-pi origin. Caching error responses, including 404s, can lead to all sorts of trouble and isn't worth it IMO.

Actually, generating heavy to process 404s is a fairly common attack, for some kinds of site.

Could you maybe provide a practical example of such a "heavy to process" 404? I'm having difficulty to image how a "Not Found" could (or ever should) involve heavy processing. AFAIK, a 404 should be only given for a non-existing resource (e.g. file). That should be straightforward enough. Granted, I've seen some horrible semantic resource pointers/paths in URI's over the years, some of which requiring processing, and some of them generating 404s. However, such contortions are mostly just a testament to horribly bad design. If the request involves processing on the server side (higher up than the web server or cache itself), resulting in a conclusion that a resource is unavailable, should that not return a 5xx response?

"We couldn't find /<requested-page>, were you maybe looking for one of these similar pages? <list>" is something that I've seen before

The origin server might be set up to serve everything through cgi. That would mean loading the entire framework just to spit out a 404 for the favicon. If all the other pages cache just fine, you could hit 100% load on favicons when you'd otherwise be at 10%.

It's not an ideal design but I wouldn't call it 'horrible'.

What is CGI in this context? I’ve only heard of it in a movie special effects context.

The web server having to run an external program to handle the request, typically because it's written in a scripting language.

Technically it stands for "common gateway interface" but that doesn't come up very much.