Addit: If you are not making hundreds, there are at-the-encoder i2c solutions, that place a MCU at each encoder ( little MCU these days are cheaper than cables !)
https://www.duppa.net/shop/
those have 32-bit i2c counters, mounted on the back of the encoder, and one supports a nifty RGB illuminated encoder.
I seen these. They aren't cheap especially if you wanted 6 of them! When I seen them I thought, well, if I was to buy those, why not make something instead.
I had a play last night. An STM32F103, 4 timer based encoders, SPI uplink to the main UI. Interrupts of the switches. On change handler to filter the output. Debug UART. It was rather straight forward to get one encoder working. 4 should mostly be copy and paste. The F103 has very little left, it maybe has about 7 usable pins left. Each encoder has a small struct which is sent over SPI "onchange".
I actually went off on a tangent trying to implement the full button state machine events like, Down, Up, Click, Hold, Release, Double Click. The first 3 are easy enough, the later 3 require state machine and timers. In the end however I came face to face with the fact that to implement all those "events" properly, I would need to think it through carefully and create some form of event system, winging it and hacking it would just lead to tears. Up, Down and Click will be fine for now
Good points on the bouncing interrupts. I will get the same for the switches, but in testing it doesn't seem that bad, they are quite heavily gated microswitches so you have to push them quiet hard and then they "SNAP" closed with a tactile click. I know they will still bounce, but the onchange handler will stop some of the outputs.
On polling a higher number of encoders. It sounds interesting. I have done the state machine variant before, we had a discussion in here about it. I favoured the approach of ignoring everything except what are valid transitions between previous and current states. It still suffers from bounce, as we discussed, but, it seems solid enough with a new encoder. It might not work as well with a dirty old encoder.
Assuming I carry on with the F103 approach, the plan is to make it a PCB with the rotary encoders being mounted mechanically to the PCB via their ring nuts and the pins wired to the board with short wires. This combines the front panel creation, as I can make the PCB front panel sized, use black solder mask, have the 4 encoders + their MCU on the panel and a large hole and mounting screws for the TFT screen. I don't need to fix the size of the device, if I need it bigger than I make the front panel, I can just seat the front panel into a larger 3D printed lid.
EDIT: What about the other 2 encoders?
Well, as I said, 4 of them are volume controls, the other 2 are more complicated and will change many different parameters. So it will be far easier to deal with it local to the UI MCU. The timer encoders have state (the count). The 4 volume control board SPI is bi-directional and the UI can send an interrupt to the encoders and send new state for them all, such as at power on to select a default profile or initial volume state. Trying to use this to set the encoders range, step size etc. Would be a complete pain. So they are probably better off local.