We are trying to convert an organization to Agile software development (TDD, Continuous integration, pair programming and code reviews, Scrum, Refactoring).
One "selling point" that someone proposed is to advise people from a career point of view that Agile software development, whether today, tomorrow or some point in the future, will be considered a required prerequisite for a top professional software job. Do you agree with this statement?
Agile is more a philosophy about choosing which skills and tools to use and how to use them rather than a skill itself. Agile tools and techniques are certainly worth knowing as a developer, whether you use them or not, in making yourself a better all-around developer and qualifying yourself to work in more situations. Will all companies develop software using an agile philosophy? Will all companies using agile methods use the same tools and techniques? The answer to both of these questions is undoubtedly "no." But you can use TDD in a non-agile environment as well, albeit in different ways and at a different level. Code reviews are valuable no matter what software development method you use. Communication -- which is what pair programming and the daily SCRUM are about at their heart -- is always important.
The bottom line, for me, is that while I can't say that "agile" will take over or be the dominant programming method, learning the skills that most agile methods emphasize will make you a better, more employable programmer.
This is subjective, but I believe the answer is no. There's never been a prerequisite for waterfall.
If you want software engineers, you might have a prerequisite that they studied software engineering in a recognized school, in which case they will know the main paradigms at the time.
But "agile" methods are not an end in and out of itself, they are part of a toolkit, and should not be applied to any and all situations.
I think everybody who programs for a living ought to be aware of it. That's different from your chances of having real experience in agile. Until there's a universal agreement on what agile is, and it's ubiquitous throughout the industry, I don't believe it'll be a prerequisite. And I don't see that as a problem, because a person who's talented at development should be able to be agile. It's more of a social problem than a technical one.
Some of the agile practices will inevitably become mainstream because they work. Out of your list, I would put these three firmly in that category:
Agile processes in general are here to stay, but not everybody can make them work, and they are not suitable for all types of projects. They will never be a "required prerequisite", but you might find yourself restricted to certain industry sectors if you don't have these skills.
Some of the other features of specific agile processes are definitely niche, or fads. But that's OK because these will fall by the wayside as time goes by.
At some point in the future, something different will come along. This may well be informed by Agile, but it will be fundamentally different in some respects.
Knowledge of Agile as an organizational pattern (the "what", which is what Agile is about) and how to conduct change is important for someone doing coaching in this area. Agile as practices and rules to be used by management, customers, and project management to maximize the productivity and value of a development effort do talk to the business.
Knowledge of engineering practices (the "how") that are just a mean but not an end, is important but less important than the "what" especially as selling point in my opinion. Engineering practices don't talk to the business.
And I believe this is why Scrum succeeds where XP failed. Don't misinterpret me, I value XP very much, it's just that Scrum is easier to sell than XP for the mentioned reasons: Scrum talks to the business (and this is precisely why Scrum authors decided to not be prescriptive about engineering practices).
Just remember that you won't sell aspirin to someone who doesn't have headache (but I think that more and more people will need aspirin, or die).
Being able to program is a required job skill.
Every business has processes; whatever flavour of Agile one business chooses to implement as the software development process is simply a matter of training. It might take a few weeks to bring somebody up to date on how your company implements Scrum; it takes years, maybe decades, to really master core design/programming skills.
Methodologies may be important to the people/businesses using them, but they are hardly central to one's ability as a developer.
Top software jobs tend to be heavy on designing system architectures. The trouble is, you cannot test, code review, or continuously integrate your way into a good architecture. Architecture is something that is imposed from outside the code, hopefully by a benevolent dictator with lots of experience. Of the thousands of failed software systems, most were killed by architecture, not code quality. (In fact some product lines have been killed by solid code hiding an architecture that cannot survive contact with the future. Rails/Django versus Enterprise Java Beans?) Ditto for the business analysis that precedes architecting.
Agile strikes me as a formal implementation method, which means it is for the operations leader and the middle-tier engineers who work for them. (The operations leader might not be an architect.) A structured checklist of activities can be valuable here to keep people from missing the forest for the trees. However it is not a silver bullet that guarantees the system will be appropriate.
There is also the question of what you mean by "top". The most highly skilled people in any job, or ones who lead the highest levels of the project? You probably mean the former; it is a matter of perspective but the distinction is relevant.
And let's not ignore financial and security work, where ideally the coders never learn the identity of the reviewers. (Collaboration == potential collusion.)
These agile methods skills are required job skills: