I'm primarily a low-level C++ systems programmer, and most of my work has been in soft- and hard-realtime apps and runtimes (which is why I'm so sensitive to the RAM issue, because in my world it's extremely important to optimise the metrics that matter, because optimising things that matters less hurts you, and so we spend a lot of time figuring out which metrics matter and when) but yes, I recall using VB6 or Access for some internal management apps.

VS Code might be using close to 1GB with nothing loaded, but it doesn't go much higher with stuff loaded, at least not that I've noticed. I do have 16GB because that's what you get in a laptop these days, and I'm always running at least three Electron apps concurrently, a browser with about 200 open tabs, and then another one or two browser with a few tabs each (plus an email client, and of course, agents and compilers running in the background). The only time I notice an issue is when a program leaks memory.

But again, I try not to look at numbers unless I know exactly what their effect is, and I rarely if ever notice any ill effects caused by well-behaving Electron apps, and unless I notice an actual problem I try not to look at numbers, because they can lead you down the wrong path and distract you from what actually matters. Overall RAM in particular, especially when combined with low-CPU (which makes swapping cheap), is a very misleading metric because it's not easily translatable to value without lots of other pertinent information (such as how many copies of the program the average user is expected to run concurrently, how many other programs the user is expected to run and what the CPU utilisation is).

In the nineties and early oughts, I, like many other developers, obviously focused a lot on reducing RAM because it mattered a lot under the conditions back then. Over the years, it started mattering less and less, to the point that you need a very clear justification to optimise it (in fact, you need a clear justification to optimise anything, or you'd end up wasting your time on optimising the wrong thing at the expense of the right thing). These days, I too often see developers trying to reduce RAM without being able to point at an actual (not hypothetical) user-experience problem they're solving.