The scope of problems being solved is much higher. Adding a two or three libraries- jquery and a plugin or two- and not giving a toss about performance was indeed easy. Few auxiliary tools were required.
Back then, we all could have a pretty strong hand on the wheel of our websites & how they functioned, at a detailed level. It was feasible, for the scope was small. But now, we all use package managers, we all use bundlers, we all use minifiers, we all use production builds, we all use tree shakers. Any one of these concerns is a significant realm that tends to have significant people-years worth of work poured into it. The need for these capabilities distances the practitioner from the core truth of the media: we no longer see clearly what we are doing, we no longer have personal stake or control in the processes.
There's still a strong latent desire to re-simplify, to de-configure the web, to de-build it. We had hopes that EcmaScript Modules would help, we had hope HTTP2 Push would be a viable delivery platform, for un-tooling, but we never really made an earnest go at tackling the optimization problems that all brought in; works like Cache-Digest never de-facto materialized or got made-available. Front-end architecture similarly has been dominated by high-abstraction top-down frameworks, namely React, which complects in a wide host of assumptions/abstractions that distance the practitioner from the actual media-form. Just as ESM was a hope that we might get back to understandable, without lots of framework/tools, WebComponents too presents a hope that we can strip away a lot of the specific complexity & find a more inter-modular, general & understandable grounding. The web can & should be at a similar power level to where it is, more so, but in more honest, accessible, direct manners than the crafted-of-necessity deep layering we cobble with today.