My view on this is that the documentation makes it reasonably clear that the intention is that CASE should short-circuit. As Aaron mentions, there have been several cases (ha!) where this has been shown to not always be true.
So far, all these have been acknowledged as bugs and fixed - though not necessarily in a version of SQL Server you can buy and patch up today (the constant-folding bug has not yet made it to a Cumulative Update AFAIK). The newest potential bug - originally reported by Itzik Ben-Gan - has yet to be investigated (either Aaron or I will add it to Connect shortly).
Related to the original question, there are other issues with CASE (and therefore COALESCE) where side-effecting functions or sub-queries are used. Consider:
SELECT COALESCE((SELECT CASE WHEN RAND() <= 0.5 THEN 999 END), 999);
SELECT ISNULL((SELECT CASE WHEN RAND() <= 0.5 THEN 999 END), 999);
The COALESCE form often returns NULL, more details at https://connect.microsoft.com/SQLServer/feedback/details/546437/coalesce-subquery-1-may-return-null
The demonstrated issues with optimizer transforms and common-expression-tracking mean that it is impossible to guarantee that CASE will short-circuit in all circumstances. I can conceive of cases where it might not even be possible to predict the behaviour by inspecting the public show plan output, though I don't have a repro for that today.
In summary, I think you can be reasonably confident that CASE will short-circuit in general (particularly if a reasonably-skilled person inspects the execution plan, and that execution plan is 'enforced' with a plan guide or hints) but if you need an absolute guarantee, you have to write SQL that does not include the expression at all.
Not a hugely satisfactory state of affairs, I guess.