The archaeology of GNOME accessibility

If your goal is removing functionality to save space, then you're going to have to make some difficult decisions where you either lose some functionality that you want, or miss out on some space savings. There's really no way around that, unless you are willing to fork components to make different design trade-offs and maintain them yourself (which you can do, this is Free Software after all, but it doesn't really scale). If the OSKs that are available to you interface to applications via ibus rather than a11y, then yes, you do need to keep ibus (not necessarily the actual Asian input method editors, but at least the framework itself).

OSKs using ibus might well be a result of the fact that few people understand AT-SPI, and those who do either associate it with more specialized assistive technologies (the Stephen Hawking use-case mentioned in the article), or have looked into its security properties and are scared of its attack surface, or both. For what it's worth, GNOME's "Caribou" OSK uses AT-SPI rather than ibus, so both ways seem to be possible.

More generally, there are broadly two ways the overall system can go to be more useful to you: it can get more integrated and tightly-coupled, or it can get more modular and loosely-coupled. Either of those might be good or bad for your goal, and it isn't obvious which. Choosing the right level of modularity is more art than science, and the right answer will be different for different parts of the system.

If the system gets more modular and loosely-coupled, you are more likely to be able to remove the components you don't need, while leaving the components that you do need, and giving other users in the same situation the ability to remove the components that *they* don't need (not necessarily the same components you remove). However, the price of a modular and loosely-coupled system is that you will not be able to get rid of the abstraction layer that links the components together (together with whatever workarounds and glue code are necessary to make them actually work), which might itself be of a significant size; and the other things you want from your system (features, bug fixes and security) will often advance more slowly, because changes require changing things on both sides of the abstraction layer boundary, and perhaps also the abstraction layer itself.

If the system gets more integrated and tightly-coupled (as in the work described in this article), then you will not be able to remove the components you don't need, because they're integrated into the components you do need. However, if they're more likely to actually work well enough that you can rely on them, and they don't have an abstraction layer getting in the way, that might well be a net improvement from your point of view.