Exception filters are not syntactic sugar because they will not unwind the stack until a true condition is encountered and you really catch the exception, something impossible to do with the traditional catch-check-[re]throw mechanism.

The point of the article was the fact there is a functional difference in how the runtime/code behaves in this instance.

Syntactic sugar would be something like automatic property getters and setters in C#; they just shorten the syntax drastically and the compiler or runtime unroll your code to the traditional implementation.

In this case you can interrogate things normally bound up into the exception instance itself, like the message without having to hit the catch block to wait for it to be hydrated. Once you enter that catch block things happen in the runtime that are costly so avoiding that if possible is the best route.

When you throw an exception on the CLR, it will 1) walk the stack looking for candidate catch blocks, and 2) if it finds one, it will long jump to that catch block, destroying all stack frames between the frame that threw the exception and the frame for the function that contains the catch block.

Exception filters are a CLR feature that modify this process a little. Now, when an exception is thrown, it still walks the stack looking for candidate catch blocks, but whenever it identifies a candidate, it will call the exception filter function (a function from exn -> bool, where exn is the exception being caught by the Catch block). If the function returns false, the CLR will disregard this candidate catch block and continue searching. C# 6.0 merely added some syntax that exposed this functionality of the CLR, the language itself isn't doing this.

Not to pile on, but: http://en.wikipedia.org/wiki/Syntactic_sugar

If the behavior can be expressed using previously existing syntax, then a construction is syntactic sugar. This is not true in this case. (sorry if you knew this already)