Maybe yours was faster, but I think a lot of people have rose-tinted memories of the speed of applications in the old days.
Then use the 10 year old version! Unless, of course, one of those few "actually useful features" is something you can't live without.
A lot of people use Word for a lot of use cases. The value of an added feature that someone needs always trumps the performance cost of adding it until the performance becomes so bad that it becomes the reason that other people stop using it.
It's weird how new trends in UX design try to make a first-time user become a genius immediately after double-clicking on the program icon. The only way you can do that is by dumbing down the software to the point it can actually be comprehended this way - which makes it much less usable and effective as a tool.
If you really need a lightweight word processor, there's plenty out there. They just probably won't have a lot of the features that the big hitters have now. And if you really want a lightweight OS, there's a fair few Linux distros aimed at that market.
What do you want your code to optimised for? Fast startup times? Functionality? Extensibility? Stability? Compatibility? Security?
None of those things come magically for free, and every day that a developer spends on one is a day that they aren't spending on another. And if they are waiting until any, or all, of those are optimised for any possible scenario, you'll be waiting a long time for any software at all.
As Blaise Pascal (or possibly one of many other possible candidates) once said - "If I had more time, I would have written a shorter letter." The challenge of optimisation v delivery is not a new one.
Don't complain that you don't need those features: it is on you to choose the right tool for the right job. If all you need is a light spell check and text editing, notepad++, vim or Emacs will do nicely. Plenty of people need the more advanced features.
It's using your time to do something else, such as improving security, or adding a new feature. Some people seem to be talking as if it automatically takes the same amount of time to create efficient code as inefficient code, and the idiot developer has simply forgotten to add the -run_faster option on the compiler.
I'm involved in a project at the moment where a team of developers and engineers have spent much of the last month trying to get response times in some very specific circumstances in an application down to an acceptable level. That's not because they are either stupid or lazy. It's because these things are hard - there's an awful lot of moving parts, and an awful lot of things that can go wrong in each of them.
When they get it down to an acceptable level, they'll ship it to the users. It won't be blazingly fast, but it'll be good enough. They could definitely spend longer tuning it further and getting it going even faster. But every day they do that will be a day longer until the features that the users want are actually available to them.
The reason there's lots of moving parts is because modern computers, OSs, languages, application servers, libraries, databases etc are built to do a lot of very complicated things.
We could have written the entire application from scratch, not using any 3rd party elements so that we had full control over every element. But that would have taken several orders of magnitude longer to deliver actual useful working software to the users.
And rewriting them, along with modifying the rest of the application to use them, takes time and can lead to further unexpected behaviour.
Here's the bits that aren't robust enough: any open source that isn't either used by thousands, or used in exactly the way you will be using it.
That 95% would still need to interact with my new 5%, and as it was never designed to do that, it could easily introduce new unexpected behaviour. Imagine trying to rip out (for example) the indexing code out of a database because it's performing badly and then rewriting it.
It's a 3rd party commercial platform for developing your own applications on. To rewrite individual bits that aren't working efficiently would be a nightmare.
As for imagining having full control over the behaviour of my code - I had that quarter of a century ago or more when I started coding, and spent weeks or months building windowing systems and low-level networking code in assembler that I could achieve in 30 seconds with any off the shelf language these days.
Yes, my code was extremely efficient (it had to be, trying to do graphical comms software on 8086 machines didn't give you much of an option to do otherwise), but the use of my time wasn't.
The third party product that we're using is the result of many years of a large team of dedicated developers. Rewriting that from scratch in order to make sure we've got full knowledge of what's going on is an utter ludicrous idea.
Or the failure of a large team to properly manage software complexity.