Android also uses implementation approaches like a component lifecycle, the Zygote, and limited per-process heap size that reduce runtime memory use at the Java runtime layer.
The people who designed the Android runtime had also designed the Danger system, which used Java and ran in as little as 32MB of RAM.
While it is possible for an app developer to make an inefficient Android app, it is very likely that core phone functionality, like dialers, messaging apps, PIM apps, etc. are a lot more efficient implemented as Android apps than as Web apps.
Second, it might be true that a single app could be more efficient as a native Android app than a web app. But regardless of whether it is (and I'm not sure it is - we would need to measure), the issue I mentioned is that Android phones have to support both native apps and their entire graphics stack etc., and the web platform and its entire graphics stack etc. Both because users can run both Android apps and a web browser, and because Android apps can embed a web view, so the combination happens even in a single app.
That fundamentally adds overhead. Of course, in theory massive amounts of work could remove it (you could unify both stacks on a single graphics codebase, and to some extent that is true on Android), but that might introduce compromises as well, and no one wants to compromise the high end which competes against Apple.
The bottom line is that Android doesn't ship super-low-end phones. That might not only be due to technical issues like these, of course.
As for how that's done, it's because Android can aggressively "swap" (really serialize and reconstitute)background components out of memory, and it can do the same to whole processes. You can actually watch your Android app instance switch PIDs, as it comes back from having had all the components, and the underlying runtime instance, killed. Now, there are some fat slovenly apps out there that might not be happy with life in a very limited machine, but I bet those 1500rs phones push the minimum specs pretty damn hard.