Yes it is very much alive, though today it's the more common "V model" that is used.
In either case, the problem that Agile has is that the solution almost never ends, the customer can continue to request changes and the development will continue to iteratively resolve them. For a project that is based on time and materials costing, this works very well. For a project that has a fixed cost, it doesn't.
For these fixed-cost projects, the customer almost always expects pre-defined milestones to demonstrate progress, however, these are more of the formal written variety rather than working code. For customers like this, the written specifications become the project, one where the software development is a secondary consideration (as they assume, if you have a well-defined project, the software should be easy to develop). These companies are also the ones that make heavy use of cheap, outsourced development resources.
So, if you have a fixed pot of money or time, do not expect the requirements to change or are not allowed to change any requirements, and are expected to supply a strong set of written documentation, then the waterfall models are the only ones that make sense.
Agile can be introduced in the middle of these projects to do the development, but you still have a ramp-up phase where the specifications are created from requirements, and a ramp down phase where the software is installed and tested in situ. Agile doesn't respond well to these cases.