True, such a low number of production units design would really only make sense if you could find an off the shelf solution to drive multiple displays.

If these displays are not supposed to be animated and they're reasonably low resolution (say, 800x600 20bit RGB or less), they could be connected via SPI and pretty much every microcontroller out there has multiple SPI ports, so even a cheap SBC would work for that). However I expect that getting XWindows or Wayland in Linux to work with such displays would be a PITA.

I've only ever got software running under Linux to control a tiny 2-tone display via I2C - on an Orange Pi SBC - and it's totally its own thing which happens to be running under Linux sending low-level commands via the I2C dev and not at all integrated with X-Windows or Wayland. This would also work fine if the comms was via SPI (in fact the code barelly changes since I'm using a library that does most of the low-level work for me).

To just display a static image or a sequence of static images loaded from storage in a bunch of screens low-resolution enough to support SPI (so 800x600 or less) I expect something like that would be fine.

The more I think about it, there more I expect this thing could run on a single $50 SBC as long as the connector exposes at least an SPI device and 8 independent I/O lines (given how SPI works, shared SPI bus is fine with one separate Chip Select line for each screen as long as the SPI device under Linux can run on a mode that lets your code control the CS line itself, and the other 4 I/O lines are for touch detection) assuming touch position is irrelevant.