There's another side in need of compiling large projects regularly, which I didn't encounter much, but if my newest MBP with i9 took around 20 minutes to compile haskell-ide-engine, I imagine what compile times you can hit potentially in bigger projects and how unbearable it could be on any less powerful machines.
Android Studio is worse. Sometimes when AS is locked up for one of its ten minute fits I'll kill it and fire it up in power saving mode which is usable, but then there's no code assist, or I'll just open up Sublime and bet on writing my code perfectly enough to compile without mistakes, which is a big time penalty.
Popular theory here is that Apple and Google have even more fancy work stations, so they don't write their IDEs to run reasonably on ours. So I'd consider 8GB to completely unusable as a mobile dev or a popular 100-200MB size app. You may be right about editors and compilers, but these are IDEs.
It's not that the system is unusable, it is just really slow, and that really hurts usability.
This is for (very large) web app(s).
You're right that editors and compilers don't necessarily require a lot of computational power, so programming doesn't necessarily require a computational powerhouse. However, lots of professional development (or the majority of it?) is nowadays done with an IDE rather than with just an editor and a compiler, and full-featured IDEs tend to be heavier especially in terms of RAM. Also, compilation can take significant time if the project is large.
My current no-GUI hobby project written in C takes about half a second to compile from scratch on my laptop, but build times of 10 to 60 seconds aren't uncommon for Java web application projects.
As for memory, a major IDE used e.g. in Java development might gulp down a GB or two depending on your project, or on whether you need to have multiple projects open at the same time, etc.
In case of server-side Java development, you'll be deploying the software on an application server or at least using a Java-based web application framework of some kind. If your software is large or you happen to be using a heavyweight application server, this might take up anything from a few hundred MB to something in the gigabyte range.
Mobile developers aren't deploying on application servers, but I suppose they also need to be running some kind of a phone simulator or something to run their apps.
If you need a virtual machine e.g. for testing on a different OS, that's going to have an overhead of a few hundred MB per VM.
Add in a browser that tends to have quite a lot of tabs open (because you usually have at least a few tabs open for reading basic documentation or specifications, plus whatever other information you need to be looking for in your current technological rabbit hole), and that can take a couple of GB, too. That's of course in no particular way specific to software development, but it does add up.
So, to pull some numbers out of a hat:
- base operating system: ~1.5 GB
- an IDE: ~1.5 GB
- an application server or other platform for test deployments: 1 GB
- browser with a bunch of tabs open: ~2.5 GB
- a virtual machine, or some kind of a background service running in a container: 1 GB
That's already 7.5 GB for a project that's not necessarily even huge. Assuming you've got 8 GB of RAM, that leaves only 0.5 GB for everything else (assuming no swapping).
Running out of RAM isn't a hard wall, at least not for most development, but it could slow down e.g. compiles of large projects if there isn't enough free memory left for a nice amount of disk cache. I wouldn't mind developing on 8 GB provided that the projects aren't that large and that there's a fast SSD, but having more may have its benefits.
Java is of course notorious for its memory use, so some developers using more lightweight platforms might have a different experience. Of course if they happen to need any other memory-hungry tools or services running on their local machine, that could again change things.
TL;DR: Editors can be lightweight, and compilers can compile a small-ish codebase quickly. The complexity of the tools and infrastructure used for professional development often changes that.