Disclaimer: I'm not an OpenWrt developer and can't speak for them.
The question isn't about "should", but "can" - if you look at the ar71xx-tiny target as an example, you see the sysupgrade images currently (18.06.2) have a size of around 3584 KB (and that's not really representative, as 18.06.x is still on kernel 4.9 for ar71xx, for kernel 4.14 you have to add just shy of 192 KB growths - and that's the kernel alone, userspace is growing as well), even on devices that use a very economic partitioning, you lose at least 192 KB to bootloader/ bootloader environment and calibration data, another 192 KB (= three erase blocks) are the bare minimum for the jffs2 overlay to work (and in practice you need at the very least 4 erase blocks (256 KB) for a most basic configuration).
128 KB (u-boot/ u-bootenv)
+ 3584 KB (average 18.06.2 ar71xx-tiny sysupgrade image size)
+ 192 KB (needed on top for kernel 4.14)
+ 192 KB (bare 3 erase blocks required for jffs2)
+ 64 KB calibration data
=========
4160 KB
Oops, even assuming zero growths for the rootfs (userland), this is not going to fit into 4096 KB anymore. Yes, this calculation isn't 100% correct, as compression efficiency might sway the numbers slightly, but the tendency is spot on - and many of the affected devices with 4 MB flash are more wasteful in terms of their partitioning. So unless anyone steps up (very soon, basically it's already to late for that now), providing actual patches, 19.03.0 (as we know it, with opkg, luci, ppp support) won't fit on any 4 MB flash device anymore.
Keep in mind, this is not a fault of the 'evil' OpenWrt developers, on the contrary - they've spent considerable efforts to create the tiny target in the first place, to allow saving as much space as humanly possible (otherwise 18.06.0 wouldn't have existed for just about any of the 4 MB devices). And the estimates above already assume 0 byte growths for the rootfs (which is unlikely). A considerable amount of effort has also been spent to push support for these affected devices to use a dynamic partitioning split, in order to make the growing kernel fit at all (most had a fixed size limit between 1.3 MB and 1.4 MB for the kernel). So please don't assume bad faith or an active unwillingness to keep these devices working, really hard work has gone into supporting these even recently.
Considering this, what are your suggestions here?
The only place where one could (relatively easily) save a few more bytes is not including opkg and luci in the images, will that help in the medium term - no, because kernel 4.19 will grow again (that's not a guess, but a fact based on the already existing 4.19 support for some targets, assume at least a bit over 100 KB there). So all you can get with this alone is maybe another major release.
Just to re-iterate this explicitly, no one has suggested to remove source-level support for the affected 4/32 MB devices so far (on the contrary, you will still find source-level support for 16 MB RAM devices, even though they have no chance to even succeed in booting a release- or snapshot image). This means you will still be able to build firmware images for these devices for quite a while longer, but you will inevitably have to make hard choices about which (basic) features you'll have to cull from your custom images (and this will get increasingly harder over time).
Do you really think supporting novice users to configure their devices using ssh alone (because the webinterface simply isn't going to fit into (remotely) release-style image anymore, pretty much regardless of what you do) would be a raging success? Oh, and opkg or pppd aren't going to fit either, so you'd need to teach them about (at least) imagebuilder and/ or building form source at the same time…
Continued support for these devices really needs very active help, as you can't expect the existing developer base to 'suddenly' find a miracle they haven't been able to find within the last >5 years. It's not as if this would be a surprise, kernel- and userspace components have been slowly growing since the dawn of time, for at least 4½ years (15.05.0) it is becoming glaringly obvious that 4 MB flash has come close to its end (given that most affected devices had 5 erase blocks (320 KB) left at most), with it just being a matter of time until it won't fit anymore. Both 17.01.x and 18.06.x (18.06.x wouldn't have fit at all, without the introduction of the tiny sub-target) showed serious problems with the firmware images fitting already - and unless you do drastic last minute changes to the configuration (removing opkg, luci, etc. from the release images) 19.03.x most likely won't fit on any 4 MB flash device anymore (again, we're talking about release images here, that won't prevent you from building stripped down images yourself!). If you consider that 19.03.0 is pretty much just around the corner (weeks, not months left), it's effectively already too late for them.
Just please don't let your only suggestion be "then don't update the kernel, libc, $userspace_in_general", that's almost the only option that isn't on the table - if you don't care about security issues, bugs or support for newer devices (yes, there has even been support for new 4 MB flash devices added to OpenWrt recently, even though the developers are starting to push back against new additions for these underspec'ed devices), others do very much. The current set of developers simply can't keep track of even more concurrent kernel versions in parallel (even for still supported LTS kernel lines this is a considerable amount of work, with basically zero on-device testing happening).
…and if you don't care about glaring security issues anyways, no one will stop you from using older versions and to become recruited by multiple nefarious botnets - just be aware that this is strongly recommended against.
As you'll notice from the figures above, very little of the image growths stems from active decisions of the OpenWrt developers - it's mostly down to growing space (and RAM!) requirements of the various upstream projects (who generally consider smartphones to be 'embedded' and low-spec, the lowest common denominator they care about), if you want to change anything, that's where you need to start working (with the relevant upstreams). OpenWrt can't diverge from upstream much more, without losing track of current upstream work and the option to support new devices users actually care about.
