This comes up at least once a week in the forums. Someone tries this:
PRINT 'This prints'
SELECT * FROM doesnotexist
PRINT 'This does not print'
That is, the error appears in the TRY block, but since this is a compilation error, you the local CATCH block does not fire. It there is a calling procedure and it has a CATCH block, that CATCH block is entered because of the error. But who says that there is a calling procedure?
This is furthermore aggrevated if there is a BEGIN TRANSACTION in the TRY block; the transaction remains active after the procedure exits, which can have very unpleasant consquences if the programmer has not catered for this situation.
I remember that in some beta version of SQL 2005 the situation above resulted in an access violation, and maybe it was OK for in SQL 2005 when TRY-CATCH was a vast improvement over what we had before. But two releases later, no, this is not OK anymore!
It's a matter of making it possible writing reliable code: since you insist on deferred name resolution, this error is by means unlikely at run-time. This fact is alone very bad, but not being able to handle it appropriately is even worse.
It also a matter about the faith in the product. When people start to play with TRY-CATCH and then find that it doesn't work accoridng to their expectation, that is not likely to increase their faith in SQL Server - it could even be decisive factor that makes them think that SQL Server is so buggy unrelaible that they make Oracle their choice.
There is a duplicate entry for this Connect item, http://connect.microsoft.com/SQLServer/feedback/details/496758/try-catch-should-capture-the-parse-errors which you closed as Won't Fix. Please don't do that ever again! The current behaviour is bad, bad, bad.