Update: one of the Atom devs closed the issue because:
We don’t feel that adding a third grammar system to Atom is going to be beneficial to the ecosystem as a whole.
No idea who “we” is, or how they came up with that decision, or when. Instead, the Atom dev linked me to the other discussion I linked here. I’m not sure that he noticed that I was part of that that discussion.
Well GitHub has a core team assigned to Atom development and they don’t necessarily communicate everything via issues or pull requests. It’s an open source project, but very strongly driven by GitHub, not by “the community”. They probably had a meeting 
If true, it makes their argument of “why Atom should be bossed by a proprietary company” quite a lot weaker though 
It’s never in doubt that Atom only exists because GitHub thinks it’s useful to spend a couple million a year on it. Same as VS Code and MS. I guess “proprietary company” here means any company other than the one who pays the bills. It’s no different from how any other large open source project is ran though, although the “community” has a tendency to be “surprised” (if not outraged) whenever anyone breaks the spell.
For anyone that finds this thread, there’s now a TreeSitter package for Sublime Text: https://github.com/sublime-treesitter/TreeSitter.
It provides Sublime Text with a performant and flexible interface to Tree-sitter. It works out of the box with around 40 languages, and can be configured to work with any language that has a Tree-sitter grammar.
Tree-sitter builds a parse tree for text in any buffer, fast enough to update the tree after every keystroke. Sublime already has a great syntax highlighting system, but Tree-sitter parse trees can be used for a bunch of other things as well.
The package ships with commands for “tree-based” selection and navigation. For example, you can select ancestor, descendant, or “cousin” nodes based on the current selection. This e.g. makes it easy to select the whole class or function if your cursor is currently “within” that class or function. You can also go to symbols returned by configurable tree queries, with symbol breadcrumbs for context.
And it exports APIs that let package developers build Tree-sitter based packages and custom commands.
The commands are useful, however, the real benefit (to me, at least) is to have better scope detection for plugins, especially themes.
Will having the TreeSitter plugin change the scope of different nodes when installed so that themes will automatically pick them up? Or, is its representation of nodes entirely distinct from the built-in scopes?
Plugins can’t modify syntax highlighting. They can add regions, which may to some extend may be abused to add something like semantic highlighting, but that may tank performance on large source codes.