Good question: the short answer is "no", not currently. It is possible to enhance pagespeed to allow it to be configured to cache a lot less data, but that's not possible today with any existing options.
As you've observed, set the cache very small and PageSpeed won't optimize your website, but it will spend lots of CPU attempting to optimize on every request, and then forgetting the results the next time it gets a request and doing it all again. And if you set the cache clean-interval very small, it will also keep the disk subsystem very busy, cleaning the cache of anything written there in the last second :)
It's a very good point though, that PageSpeed's HTTP cache is somewhat redundant with a downstream cache like a CDN or Varnish, and it would make sense if we could disable the HTTP cache. However, PageSpeed's operation critically depends on a metadata cache and, to a lesser extent, a property-cache. The metadata cache tells PageSpeed "I've seen foo.jpg before, and I I've already optimized it for the current browser (say mobile Chrome), renaming it to (say) foo.jpg.pagespeed.ic.hash.webp". If that metadata cache always fails (returns a MISS), PageSpeed will have to re-optimize the image. Basically it's a non-starter IMO. However, the metadata cache is very small relative to the HTTP cache.
We could in principle disable the HTTP cache. There's no way to configure that now, but it might not be that hard to add. I haven't fully thought through what happens if we do that. One disadvantage is that we'd have to do more internal fetches. For example, the same source image, foo.jpg, may need to get optimized up to 8 different ways: for (mobile | desktop) * (webp | non-webp) * (save-data | not-save-data). Currently it just gets fetched from origin once, and saved in PageSpeed's HTTP cache, from which it could get optimized on-demand for all 8 possible client combinations. In the absence of an HTTP cache, that all still works, but it would just have to fetch the origin resource each time, until the metadata cache was warm.
InPlaceResourceOptimization would also stop working (unless LoadFromFile was enabled). This is because InPlaceResourceOptimization for ngx_pagespeed and mod_pagespeed both work by collecting origin resources as they stream through the output filter, and saving them in the HTTP cache. The image/css/javascript optimizers don't kick in until the image is in the cache. I think it might be possible to change to buffer the resources and optimize them in-stream, but that would be a fairly significant change.
There's also the property-cache, which helps with prioritize_critical_css, inlining images that are above-the-fold, and a few other cases. That's similar to the metadata cache -- a CDN's cache wouldn't really help for either of those.