Emacs is more like an ecosystem, within it you absolutely can and do have specialised tools for different purposes.
The benefit is that, traditional process based boundary forces you to use IPC mechanism for combining different tools, e.g. unix pipes. This is fine for many things, but your communication medium is usually still a stream of bytes with no structure. Unless what you want can be achieved by simply combining two or more tools, when you write bespoke tools, you end up doing serialising and deserialising data over and over again just to send through pipe.
In Emacs all "plugins" reside in same process space, so they aren't handicapped by requirement of structure-less IPC. You can simply write functions that work on each other's structured data. This is more pronounced in case of TUIs such as ncurses programs (as opposed to CLI programs), they can't be composed or combined with each other easily, but in Emacs that's not a problem because underlying data layer remains accessible all the same. Overall, the mechanism of composing multiple specialised tools to produce gestalt effect is arguably more streamlined in Emacs, not less.
On the flip side, this homogenous ecosystem comes at the expense of not having an array of languages at your disposal like in unix. But tbh elisp is a fine general purpose language, so that's not as big a problem as you might think. There are other concerns like security, plugins being able to peek into another's data is one of seminal reasons why OS process as boundary is a thing.
The benefit is that, traditional process based boundary forces you to use IPC mechanism for combining different tools, e.g. unix pipes. This is fine for many things, but your communication medium is usually still a stream of bytes with no structure. Unless what you want can be achieved by simply combining two or more tools, when you write bespoke tools, you end up doing serialising and deserialising data over and over again just to send through pipe.
In Emacs all "plugins" reside in same process space, so they aren't handicapped by requirement of structure-less IPC. You can simply write functions that work on each other's structured data. This is more pronounced in case of TUIs such as ncurses programs (as opposed to CLI programs), they can't be composed or combined with each other easily, but in Emacs that's not a problem because underlying data layer remains accessible all the same. Overall, the mechanism of composing multiple specialised tools to produce gestalt effect is arguably more streamlined in Emacs, not less.
On the flip side, this homogenous ecosystem comes at the expense of not having an array of languages at your disposal like in unix. But tbh elisp is a fine general purpose language, so that's not as big a problem as you might think. There are other concerns like security, plugins being able to peek into another's data is one of seminal reasons why OS process as boundary is a thing.