We've found that with the right code, the 437 is more than enough to do what we need to do with image data. STM32 performance is only increasing with time, so this should open up more possibilities (e.g. the H7 parts look to be something like 3 times faster than the 437).
I can't give details of our application, but see for example the OpenMV ( https://openmv.io/ ), which does a pretty wide range of useful stuff - face and blob detection, QR code and other tag reading, etc. On the STM32H7x3 (as far as I can tell - I haven't tried this) it should be possible to JPEG encode images in hardware, which would give a data rate that can be pretty easily handled for streaming or storage.
Note that it is still useful to be able to achieve higher data rates even if those data rates could not be processed if used at 100% duty cycle - many newer sensors have only CSI-2, and must send data at a fixed (fairly high) rate, however this rate only occurs in bursts during frame readout. In normal use the average data rate is lower, and data can be buffered. If necessary many sensors can be operated at lower resolution, bit-depth and/or frame-rate to reduce the average data rate further. The problem is mostly just in implementing the data interface itself and handling the required clock rate, not dealing with the average rate of data arriving.
The advantages of using an STM32 are reduced cost and complexity, easier implementation of hard real-time image processing, better selection of low-level peripherals and much better documentation and lifetime relative to a cost-effective SoC (and possibly even compared to one of the pricier ones aimed at industrial use), so I think there's a very real niche for STM32 in imaging applications.
