You realize that although WebKit supports 98%, Safari itself as of version 9 supports 53%. As is noted in your own link to the compatibility table. So, yes, keeping pace is a problem for Apple, since the other browsers are significantly ahead and the Safari 9 series was released half a year ago. Even Microsoft Edge has been doing better.
You might actually have a leg to stand on when Safari 9.1, released 10 days ago, gets its ES6 state tested and uploaded to the compatibility table. Or it might be more embarrassment about Apple's slow release cycle. It's also unclear as to whether Safari Tech Preview will contain the majority of ES6 code in Webkit or if it will be "curated" into a significantly less compliant and useful state. Once again, tests will tell. What is certain for now is that six months of Safari have left it at 53%, which, among many other examples, has been Safari dragging everyone else down.
Just because they have untested, unsupported code in a development branch doesn't mean that their main browser with a completely different name and a glacial release cycle gets a pass for holding up the class. The Tech Preview is a good starting step, but until these things have a clear release cycle that shows current WebKit ES6 feature support making its way into a release build before the end of the year, we'll continue to be upset at them with cause.
It's also unclear as to whether Safari Tech Preview will contain the majority of ES6 code in Webkit or if it will be "curated" into a significantly less compliant and useful state.
Apple has been clear from the moment they released Safari Technology Preview:
Get a preview of the latest advances in Safari web technologies, including HTML, JavaScript, and CSS. Safari Technology Preview includes the most recent version of WebKit, the rendering engine that powers Safari.
The most recent version of WebKit does not automatically mean that it's a scheduled build directly based off of their development branch. I agree that's the most reasonable way to do it, and it's what it implies. And it's easy to assume that's what they're doing. But they could just as easily be putting this in an intermediate tech preview branch and pulling individual commits.
The phrase "most recent version" could mean pulling from a dev branch, using the last successful build, pulling from a release branch, pulling from a testing branch, assigning arbitrary numbers and tags to commits and pulling from there, or even working from a staging repo where they cherrypick commits. These are all separate sources that could hve their own version series, and "most recent version" is a very relative statement. Anyone who's seen the divide between development and sales knows that phrase has enough wiggle room to fit a Challenger disaster inside, and marketing is Apple's specialty.
I really hope they start to pull the changes from WebKit. Safari sorely needs it. But Apple's not the kind of company you just take at their word unless it's independently verified. I get it if you want to believe. That's sweet. But I'd rather wait for the tests.
Even then, monthly builds are still not a public release schedule for Safari. It was six months with only minor fixes between 9.0 and 9.1. We're far more interested in a public stable release with usable ES6 support than builds with unstable features that won't be usable on sites this year. If preview builds were what would solve the problem, then the WebKit Nightlies would have been enough.
Now with Safari Technical Preview, if you want access to all of it in a more accessible package than the WebKit Nightlies, you can have it.
BTW, Apple has been doing what appears to be a amazingly good work on JavaScript Core lately, extending their performance lead: https://webkit.org/blog/5852/introducing-the-b3-jit-compiler....