I'm failing to see how ASC and DESC would apply here, unless someone is simply passing them on directly from a URL or input form into the SQL, which is almost the equivalent of just letting the user type in the SQL directly. Also, the worst thing that can happen to an extension like LIMIT is that more rows show up than expected, but that wouldn't change the context of the original query to return data that wasn't originally intended to be shown. Plus, it would be very difficult to tag on more SQL to a direct LIMIT number being passed in unless the back-end application was totally brain-dead about how it converted strings to integers.
One other thing - extensions like LIMIT can be parameterized also (shameless plug: our product ElevateDB can do it with its RANGE clause). It's a nice way of getting rid of this type of issue, and allows for easier pagination without having to force the database engine to constantly re-prepare the same query over and over again.
IMHO choosing between ASC and DESC isn't exposing an input into the query in the same way that accepting arbitrary text (escaped or not) into the query is, but thanks for clarifying.
And with regard to LIMIT, it's a bad idea to allow the user to pass in any values without validation, even if you restrict it to integers.
Parametrized queries help resolve the most common kinds of SQL injection, all the "yes but..." argue that it's not a blanket instrument that instantly should make you feel safe and no longer think about security/robustness. That's also true. Such a thing doesn't exist anyway.
Given a properly parameterized query, where none of the parameters are ever evaluated, how do any user inputs remain unseperated from query structure?