These are relevant only to my various and changing needs, so you maybe ignore this?

1.54" 128×64 FSTN (this) with 30 and 46 size fonts using the 4-wire SPI interface is acceptable. The illumination is even, the angles are good, the update speed is good and the artifacts are acceptable. The contrast could be better, but it's not a deal-breaker.

2.9" 128×64 FSTN display (probably this) with large double digits is a tad too slow with a 24 size font using the 4-bit interface. It may be acceptable with smaller fonts. Another pain point is the manual adjustment of contrast – with a trimmer that doesn't inspire confidence. ★ Is SPI faster?

2.9" 128×64 STN display (probably this) with large double digits had too many artifacts. It may also be too slow using the 4-bit interface.

★ Order and test other candidates?

There are three challenges with using character displays.

The first challenge is finding a display with good appearance, esp. when the display updates. The inexpensive one I tried doesn't look good enough when switching. This or this might be good though.

The second challenge is adapting a library to implement BigFont/BigCrystal with I2C or serial register. I seemed to get close by adapting BigCrystal to LiquidCrystal_PCF8574, but it's not working (yet?).

One idea to address the above is to create a dedicated controller that has a parallel connection for the LCD and an SPI or other serial receiver that accepts data to render. The formatting and display of the data would be handled by the controller.

The final challenge is whether BigFont/BigCrystal is aesthetically acceptable.

There are lots of TFT displays that experience has shown look good and with something like a Blue Pill fast enough. Whether this is a workable solution depends on whether the ucglib library works with a core that supports the microcontroller. Ucglib doesn't seem to document what boards it supports, so experimentation and some hope that updates won't bork things is the only way to do.

Candidate μCs are covered below.

Using Roger Clarke's now unsupported Arduino_STM32 core works with a modified ucglib. The required modifications are described in this bug report. Specifically:

In order to add support for stm32duino platforms the following definition is needed:

#if defined(__arm__)
#ifndef __NOP
#define __NOP __asm volatile ("nop")
#endif
#endif

Adding the definition to the file Ucglib.c worked with a maple mini clone and a ST7735 TFT:

Ucglib_ST7735_18x128x160_HWSPI ucg(/cd=/ PA2 , /cs=/ PA4, /reset=/ PA3);

The STM32duino project still seems to be active, but I have not tested ucglib with it.

★ Work needs to be done here to see whether the unmodified or modified ucglib works with the STM32duino core.

There are two different cores that let you use the RP2040: Arduino Mbed Core for RP2040 boards is an official Arduino project, but it kinda seems Earle Philhower's arduino-pico gets more attention.

★ Work needs to be done here to see which is the more promising option.

ESP32 support in Arduino has a long history. But standard boards don't really seem to exist, and it's not clear whether s/w disabling BT and WiFi is good enough. I think working through the previous two options first is the more promising path.