What was so bad about it? Or, contrarily, what did you like about it?
Real-world waterfall always contained the idea of feedback from later steps changing the results of earlier steps. (Not having this means you have to be essentially perfect in your earlier steps to avoid having garbage input to your later steps. That can't be done. What's more, circumstances change during the life of the project, and if you don't respond to that, you're programming for the world as it existed six months or two years ago, and that is a recipe for failure.) This feedback to earlier layers was considered entropy, and the task was to manage it, to keep it from running out of control. The result was that you could be implementing something a year after the requirements were done, and six months after the design was done, and if you saw any problems, you were supposed to not revise the design (still less the requirements) unless you really had to.
In contrast, agile wants to have those times as short as possible, and to feed what you discover during implementation back into the design (and even requirements), in order to get them to better conform to reality.
Real agile is all about keeping the feedback loops tight. Waterfall was all about wholly completing phases, in order. This lead to waterfall being rather unresponsive to new information or external changes. (To see how demoralizing this can be, imagine working to implement something, where for the last three months you know it's the wrong thing.)
This can drive bad behavior, pitting teams like requirements analysis, design, development and test against each other since they sometimes have competing interests.
In a larger organization, competing interests emerge since these teams are often managed by separate people who manage and measure their people with objectives that are for the role. People who write requirements get focused on common ways to document requirements, templates, etc.
A rigid organization using waterfall tends to have very structured, approval oriented deployment processes which leads to things like only having project launches 3 times per year. A weekend launch starting with a backup of the system on Friday in case they need to restore Sunday night if the long sequence of 300 deploy steps is somehow botched.
I went from organizations like above into one that uses a Continuous Delivery model. This means we deploy every day, multiple times a day if needed - to production. Small changes that are testable with builds being tested continuously, operations of the environment heavily monitored and developers own their changes into production.
The issue is that it would be cheaper to do it that way, because trying to get all requirements right and implementation right before doing was really expensive and still incorrect in he end. You'd always end with bugs or missing features...
All development process models assume the following tasks:
Requirements collection
Analysis
Design
Development
Testing
Deployment
Waterfall:
One meaning, the original and literally the worst thing ever, is that each of those activities is completed essentially in whole before the next and without feedback from the successor activities. The only feedback is when you get to maintenance and collect PRs/CRs from the customer and start the whole thing again.
The practical versions introduce some feedback loops but typically only up one level at a time. So test obviously feeds back to development which feeds back to design, etc. The problem here is that this is still a very slow process.
The problem with waterfall (the practiced version) beyond the poor feedback loops is also the time delays involved. Your analysis board which decides which PRs/CRs to work on may only meet every 6 months. So the average PR will sit in a queue for 3 months before it's even considered for work. And the results of the analysis board may not make it to the developers for another 3 months so the average PR won't be worked on for 6 months. And because many PRs are collected and started at once, integration testing typically waits until they're all done. So it could be a year or two before a full integrated build is produced and an issue discovered which forces you back to the design phase to fix a critical issue.
And, while the developers and testers are doing their thing another analysis board meeting happens and introduces more PRs. By the time a product gets released it's often 1-3 years behind what the customer actually wants or needs.
Waterfall only works if you have trivial projects, or projects with very clearly defined scopes and requirements that are being planned on the order of years or even decades anyways. This isn't most software.
The larger the batch size, the less time you spend designing, coding and delivering, and the more time you spend (mis)managing the batch - what goes in it, changing what goes in it, planning what goes in it, explaining what will go in it, explaining why half of it didn't go in it.
All of this invites a certain type of personality who is not incentivized to deliver but to talk about delivering. That is when the horror stories start.