While it's nice to not need Modernizr, or JavaScript at all, it's generally only useful for features added after the @supports support landed. As others have mentioned, there's also the problem of false positives, and you could end up with a lorra lorra @supports statements if you include vendor prefixing as well — not a problem JavaScript has to put up with, because you can just define a prefixing function and save many lines of code.

Here's the problem vis-á-vis compatibility. CSS Animations are supported back to Safari 4; @supports landed in Safari 9.

For instance:

@supports (-webkit-animation-name: blink){
.cursor {
-webkit-animation-name: onoff;
-webkit-animation-duration: .9s;
-webkit-animation-timing-function: cubic-bezier(.4,0,.2,1);
-webkit-animation-iteration-count: infinite;
}
}

That's actually damaging, because there won't be a browser that supports @supports and doesn't support CSS animation. This statement will activate the animation only in Safari 9+, despite the feature enjoying support beforehand. By conditioning the animation on support for animation-name, we're actually preventing the feature from showing up where it ought to.

Of course, @supports is very useful for bleeding edge stuff like animation-play-state, which just landed in Chrome (and I dare say Firefox) as a byproduct of the Web Animations API.

animation-play-state let's us control whether an animation (let's say an infinite one) is paused or playing. So, if you imagine a scrolling marquee (for the sake of irony), for instance, you could conditionally pause the marquee on hover by setting:

@supports (animation-play-state: paused){
.marquee:hover {
animation-play-state: paused
}
}

You may be thinking "that's effing ridiculous, I could just add that CSS property anyway and if it's not supported it won't work, simple" — and you'd be right to say so.

It would be equally pointless to write this:

@supports (will-change: transform){
.element { will-change: transform; }
}

because if the property is not supported, it simply won't do anything, and it will not affect anything else or prevent CSS parsing. @supports is pointless as a mere wrapper because there's no need for containment.

However, @supports is not for applying potentially unsupported properties only; it's for conditionally activating/altering entire aspects of your website based on there being support for a crucial feature.

More useful code might look like this example:

@supports (animation-play-state: paused){
.marquee {
white-space: nowrap;
animation-name: marquee;
animation-duration: 20s;
animation-timing-function: linear;
animation-delay: 1s;
animation-fill-mode: forwards;
will-change: transform;
}
.marquee:hover {
animation-play-state: paused;
}
}

This would be useful if, for instance, it would harm usability to have an unstoppable marquee of images/products, so with this sort of code you could have that marquee display as something more mundane, like a grid of items, and if the ability to pause the animation is supported, then convert it into a scrolling marquee gallery of items.

It's also potentially useful for things like mix-blend-mode, if you want to apply some kind of fancy effects with a fallback to a simple, one colour overlay:

.overlay {
position: absolute;
top: 0;
left: 0;
width: 100%;
height: 100%;
background: radial-gradient(rgba(31,10,25,.2), rgba(3,81,176,.6));
}

@supports (mix-blend-mode: difference){
.overlay {
mix-blend-mode: difference;
background: radial-gradient(rgba(31,10,25,.2), rgba(176, 109, 3, 0.6));
}
}

See, if you wanted to apply the difference blending mode but have a similar colour theme, the background of the overlay would need to be basically the opposite, so you can use a @supports block to conditionally change the colour to suit whatever the blending-mode requires.