The only person who can definitely answer that question is Robert C. Martin himself, but I'll try to make an attempt.
As far as I understand it, the implied scenario is that the $input parameter represents run-time input, which is inherently not type-safe.
In many application architectures, there's a boundary where the software 'meets the real world'. In a primitive application, you may ask the user to type 0 for male and 1 for female. In a console application, you're not even going to receive an int - you'll get a string.
In a web application you easily run into a similar problem. Even if you make a nice GUI with, say, radio buttons, you can't fully trust that some malign user wouldn't try to circumvent the GUI to instead give you a raw string - or, that a bug somewhere else in the code is going to do something to a similar effect.
Introducing an enum isn't going to change that. You'll still have to parse the raw string into an enum value. If the next thing you do is then to switch on the enum to produce a polymorphic object, you might as well dispense with the intermediary step, and hence, with the enum.
This discussion is reminiscent of Alexis King's great blog post Parse, don't validate, which makes a similar point: turn something less-structured into something with a better structure.
