It's not that surprising. From a technology perspective of the time, it meant that video either needed to be shifted between systems and memory mapping, which leads to software level incompatibility or you get the situation where the memory access must be performed by two independent systems. One to drive the LCD and one to drive the screen.
Although ROMs had become cheaper at the time and thus it was reasonable to splurge with lots of ROM, the C128 shows that it was possible to have two different outputs(display without causing much trouble to regular users. Sure, it was two outputs for regular CRT monitors, but from a software point of view they worked very differently. The 40 col output uses a memory mapped display, 1000 bytes for the 40x25 characters, and 1000 "bytes" that is just nybbles (4 bits) for the foreground color information for each character. Meanwhile the 80 col output is somewhat similar to the Texas TMS9918 family in that it uses just a few I/O ports where you indirectly address the video memory (16k or 64k). Thus most of the screen handling code has to be different for the two outputs. (I assume that some things like limiting output to a "window" and such might be common between both displays, and also interpreting control codes (like for example translating color change codes to a four bit value - although the palette is not fully the same, most of the colors maps good enough between the displays).
I get that it would likely be more work to get something like this going if you have a Sinclair style screen editor, perhaps?
An interesting observation I just made is that while Commodores Kernal uses device numbers for all I/O including screen and keyboard (where IIRC 0 and 3 are screen and keyboard; can't remember which is which), it seems like this is not used to differentiate between the 40 and 80 col displays. BASIC even has a CMD command that redirects standard output to more or less any device. This was the somewhat hacky way to get listings to a printer, you'd open a file to the printer device (usually 4) and then CMD that file descriptor and then just do a LIST. This is the reason for why many vintage Commodore listings have an extra line with the "READY." prompt at the end of listings.
And sure, application software would of course have to be aware of the fact that the screen could either be very small or a regular full CRT display. But BASIC programs and anything else than action games could just use the provided APIs (or ABIs as people tend to say nowadays) and as long as what you printed would fit on screen it would just work.
My thought process here is that things like the Epson HX20 were a decent success thanks to it's abilities and being one of the earliest "full" computer with a keyboard that was better than mechanical typewriters and which would run for many hours without external power. I think that many of these were used in various custom applications.
If they had had a full screen display when at a desk they would had been more suitable for more productivity style work, and it would also had been easier to write software.
On the other hand, thinking about it, IIRC at some point in time in the 80's a Z80 or 6502 cost about $3 in single quantities, so there might not had been much savings in not just having two separate computers. But then you'd likely lost out on the ability to easily share data (and use the desk system to develop for the portable system).
Going further on into this tangent: I think that a mistake the computer companies did back in the days was to not agree upon standards for talking to more advanced peripherals. Sure, RS232 and Centronics were standards (or possibly a de-facto standard for Centronics?) and the low level Shugart interface for disk drives were also a common denominator. But there were no manufacturer independent way to talk to storage devices using a serial or parallel protocol.
Sure, there were GPIB but the standard only worked as far as sharing printers between different companies (I.E. you could use HP printers with a PET and I would assume that you could use a Commodore printer with a HP computer although that would be weird). The disk drives didn't work as-is. Technically you can connect a Commodore drive to a HP computer or the other way around, but Commodore had the file system code in the drive while HP had that in the computer, and although Commodore drives have commands to read/write individual sectors rather than use the file system code, those commands differ from the commands HP drives use. So to use a Commodore drive on a HP computer you'd need to at least patch some parts of how the HP computer talks to the drive, and to use a HP drive with a PET you'd need to write your own filesystem code that runs inside the PET.
And then Atari used their SIO which is kind of like RS232 but with data from the peripherals being wire-gated so anyone can transmit on a single line. Epson used regular RS232 to talk to the drives for their portable computers. Commodore developed a serial version of IEEE-488, but this used bidirectional clock+data lines rather than just data likes like RS232.
And then there were various manufacturer specific networks.
If the manufacturers had agreed upon one standard for raw block access to disk drives, and another standard for drives with a built in file system, things would probably had been way better when it comes to sharing data and such. Sure, if this had been a thing you'd then run into problems of tokenized basic vs text file basic, but still. (A marginally related tangent is that Atari can not only save but also load both versions, and they use the text file version as a work around to MERGE programs. Unfortunately it turns out that the command to read a file as if it was entered on the keyboard can't be used with the Atari 850 I/O thingie, a box with four RS232 ports (and IIRC a parallel port?). A bit unfortunate as you need to already have software on the Atari to get further data into the Atari).