Well, don't blame T-SQL for the way CASE is defined. The ANSI SQL-92 standard defines CASE to be an expression. That is, it returns a value, so it can be used anywhere anytime in any statement where a value is required.
This is very handy when operating on sets
of data, since the expression is evaluated (conceptually) on all elements of the set all at once at the same time.
Control-of-flow statements, on the other hand, are not part of the SQL language. They are a part of, in SQL Server's case, the language called T-SQL which accommodates the execution of SQL statements, along with other operations not part of the SQL language per se. If you want to influence which SQL statements are executed, you need to use T-SQL constructs like IF-ELSE for that.
As to your comment about ORDER BY, Microsoft, or any other vendor, cannot simply change the way SQL behaves. ORDER BY is a part of the language and its specification states that it must refer only to columns in the resultset. Some vendors (including MS) have extended this to allow ORDER BY on columns of the related tables in the query not in the resultset, but you'll see artifacts of the original restriction in things like UNION queries, where the ORDER BY clause must specify columns in the resultset only. Because of this, purists would argue that this sort of extension offends their sense of, er, purity. :)
I don't actually know, but I can guess that specifying the ORDER BY columns in a parameter or other variable would mean that the optimizer could not construct a full query plan until run-time since it couldn't know which columns were to be used for sorting until then. This would mean that the pre-compile of a plan to include indexes which might significantly help the sort operation could not be done.
Or something. ;)
Custom Apps, Inc.