There are multiple ways to deal with that, for example Lazarus / LCL scales all automatic values by the scale factor. Only when someone deals with pixels directly (e.g. drawing shapes on a canvas manually) has to update the application.
Yes, in that case it wont work automatically, but it can still be good enough for most applications and the changes to make it work "properly" can still be much simpler than doing a massive API upgrade. In a desktop-based bugtracking program i wrote in Lazarus, pretty much all of the UI worked "out of the box" on a GPD Win 1 running KDE/Xorg with scaling set to 150% - except a single widget where i drew things manually. Fixing that was a matter of a few lines of code. Much preferable to having to port to some different toolkit.
Also fallbacks can still be implemented, like using shadow drawing and scaling. These can even be exposed as controls to the user via binary parameters or environment variables, thus allowing users who are not in a position to modify the program (e.g. using some old binary or found some source code that they can compile but do not really have the knowledge to fix themselves) to find a "good enough" scenario. This is why, e.g. Windows have that "Compatibility" tab in there, even if they cannot always get a 100% perfect fix.
The point is at least making an effort.
> they are impossible.
They are not impossible, most of the time when a programmer claims something is "impossible" they haven't tried or thought enough or tried to think enough out of the box: you have to take that into account from the point where you design the new features, not try to backport them after the fact.
A bunch of Gtk4 features as it exists and was designed right now with the current mindset will certainly feel hard / impossible to backport to something like Gtk1. The point is not have that mindset in the first place and treat backwards compatibility as a feature as important as anything else at all points during the development of the library.