Here are my, not Sublime HQ's, thoughts:
This probably depends on what you want different than what Sublime Text has right now. In 2016, we released a bunch of builds, and if I recall correctly, a similar number to the Atom and VS Code teams. Perhaps the features added aren't interesting to you, but there is a lot that can be seen at https://www.sublimetext.com/3dev.
Generally we don't post about what is coming next because priorities change, and sometimes ideas don't pan out. That said, I hope you all will enjoy what is going to be part of the next builds!
Part of this is probably how you think about it. From my perspective it isn't so much that there are limitations on the API, as the current implementation of various aspects are purpose-built and aren't abstracted in such a way that you can just expose a way for Python to interact with them. Instead, adding APIs requires taking the current, efficient implementations, thinking about the way in which people will want to use them, and then re-implementing them to remain efficient but also allow for the API to interact with them.
I've done a bit of behind-the-scenes work during this last cycle, in addition to much more obvious changes. A good chunk of the work I did will only be visible as performance improvements and edge-case bug fixes, but the core implementation has been rewritten and paves the way for future improvements.
A lot of developers expressed interest in HTML and CSS support, so 2016 added lots of features in that area (lots of features implemented in minihtml, phantoms support). We made huge improvements in syntax highlighting accuracy and speed, and set guidelines for the community to use in continuing to improve syntaxes. The Python environment got updated, with modern versions of OpenSSL and SQLite, plus backports of various bug fixes from Python 3.4, while retaining full compatibility with all existing plugin code. We added API controls for various parts of the UI (sidebar, minimap, panels and tabs) and added hover controls, which enabled mouse-based code exploration through the Show Definitions popup.
I have been working through various bugs and nitpicks, focusing on more serious issues like crashes or things that impede general usage. Many items on the issue tracker are enhancements, some are listed as bugs but the user just doesn't like the way Sublime Text chose to implement a feature. With the number of Sublime Text users and all of the different operating systems it is used on (and new releases of operating systems), I am not surprised that there are a large number of issues opened. But yes, we are working on them. I try to make a point of closing issues that I know are resolved with each build, but I am sure some are not closed because they can be hard to find.
I should say a huge thank you to @FichteFoll and @kingkeith (plus all of the other users), who help to manage the issue list, marking duplicates and trying to provide extra information where possible.
Most of the limitations are a side-effect of other features. Large file and long line handling is at odds with full-file symbol indexing, word wrapping, variable width font support, minimap, syntax highlight performance & accuracy. Per-window process sandboxing is at odds with low memory usage and portions of the API. Lame (naive) code folding means that code folding works out-of-the-box for lots of crappy syntaxes that exist, at the expense of precise control. Package conflicts – without specifics, this is hard to talk about, but yes, there is a good likelihood that there be problems when running code from 20 different developers who run independent projects. Remote editing and slow filesystems are at odds with performance, symbol indexing, local file notifications, Goto Anything, and other features.
That said, it isn't that we don't plan to try to improve aspects of these areas, or implement layers on top to handle edge cases. I just think it is good to be aware that tradeoffs exist, and lots of the good that people love in Sublime Text is because we have to make tradeoffs, and because we decide to make local editing of source code and markup a priority over handling multi-GB log files loaded from a network share.
I hope that my perspective at least helps you to understand how I process the issues you brought up. I definitely see people expressing them. Part of it I think is comparing large open source projects run by huge companies, with a three person (two developer) company. In the end, I believe it is all a balancing act with priorities, maintainability, vision and a diverse user base.