I believe the problem for the larger data sizes of hi-res is that the buffer in the old platform is too small for reliable online streaming. With local streaming, you have a fast and pretty stable data rate on the network. With online streaming, there can be considerable momentary fluctuations even on fast internet links. It took Naim a while to make Tidal 16/44 work reliably, and I guess 16/44 is the reasonable limit.
Regarding the availability of both Tidal and Qobuz, I believe that the memory that is available to store the firmware is not sufficiently large to contain the code for both. So they choose Tidal over Qobuz, quite sensibly.
For the platform I believe (but may well be wrong) it used Windows Embedded, which was not a good operating system for embedded machines, it was inflexible, I believe quite resource hungry (being Windows), made you dependent on Microsoft (e.g. for bug fixes) as you had no code for it, was consequently barely used in embedded machines, and has duly been abandoned by Microsoft by now.
So all in all, yes, poor design decisions in this platform. But the new platform is looking entirely sane and state of the art regarding what you do when you design an embedded machine. It has a CPU whose power seems appropriate for audio tasks with headroom to spare, it has 50 MB buffer (giving you approx. 2 minutes of fully buffered audio data even with 24/192 flac files), and it uses an operating system (Linux) that is widely used in embedded systems, is highly configurable, and you have control over and the source code for it.