I have a use case! I travel with my smartphone (and leave my desktop at home), but I receive links to huge files via document sharing sites (gigabytes and up - not the medium I would choose, but the choice isn't mine: the clients like those, for some strange reason). The links expire quickly, are not downloadable through console browsers (JS/images/CAPTCHAs), and I might not even have enough space and/or bandwidth to download them locally, to the smartphone. Up to now, I've had to resort to weird hacks such as "X+ssh forwarding a remote xpra session from the desktop, with a browser window in it", which sort-of-worked, but was painfully slow. This is a different approach, one that seems workable.
Zooming is necessary due to the smallish smartphone display, "latency issues tackled by RDP" is mostly wishful thinking (okay, it's gone from "unusably bad" to "just bearably bad").
Right so, if the previous options of running UI apps remotely don't work, you'd need a web browser with JPEG, PNG, JS and Linux framebuffer support.
Dillo and Lynx are quick. Dillo last release was 2 years ago. Lynx is in active development. They don't have JS support though.
Links has support for JPEG/PNG and Linux framebuffer but somewhere in '00s they removed JS support (it was an unmaintained port of spidermonkey). ELinks port which also supported all 4 features is dead.
There's surf and uzbl. I don't know the latter much, former is used with keyboard shortcuts only. AFAIK these don't use the Linux framebuffer. Dooble is a lightweight web browser, but no Linux framebuffer support.
I question wanting JS 24/7 locally. You can also just not load all these JS nonsense and have a quicker experience (with NoScript or uMatrix). Same with loading all images. You could use a proxy to downsize JPEG pictures as well. The very first Opera versions on mobile phones did the same thing. They didn't even serve HTML! They spoke a different language with the browser. I'm not sure if Vivaldi (formerly Opera) still employs this feature. But you need to remember there's a market for this in upcoming economies where mobile bandwidth is scarce.
"Console browsers won't work at those particular sites, because the sites are dependent on JS and image CAPTCHAs". - "I question wanting JS 24/7 locally [because you can just not use JS and you'll be fine]". What part of "if I do not have JS, it just won't work at all" did I fail to explain? Did you even mean to reply to this comment, and not some completely different one? (Rest assured that I use NoScript for my usual browsing needs, most sites cope with no-JS gracefully, and this use-case is not a typical browsing set-up, or anything that would be useful for general browsing.)
Zooming is necessary due to the smallish smartphone display, "latency issues tackled by RDP" is mostly wishful thinking (okay, it's gone from "unusably bad" to "just bearably bad").