Is this the old monolith vs micro-services argument?
I guess this boils down to 'how granular and function specific are your building blocks?' and where you draw the lines programmatically: library interfaces in a single program/executable, API/ABI between two or more programs/executables, HTTP API/other transport protocol across network boundaries between two or more programs/executables, and so on.
I'm not sure I'm slicing this along the correct abstractions, though.
The unix philosophy pertained to simple composable limited cli tools. Most of which, at least the initial bunch, where written by the same handful of people, too, and one of each only: no several competing programs to awk and grep and cut and so on with widely different philosophies. At worst you had e.g. different implementations (like Sys V vs BSD vs GNU), and even that was already bad enough.
Once you get to programming language tooling, "do one thing and do it well" is not necessarily the best course, especially when you get leaking abstractions and limited interoperability and messy choices to make where no tool is standard.
Why? Is fewer things always better? How far should it be consolidated? Taking it to an extreme, would having a tool named Everything that does anything you could imagine in relation to web dev be better?
Doesn't have to be always, it often is however. Imagine how better this would be with fewer things: https://xkcd.com/1987/
>Taking it to an extreme, would having a tool named Everything that does anything you could imagine in relation to web dev be better?
Taking it to an extreme, why not?
If it was just a tool that did everything for a language (compile, dependencies, formatting, linting, debug, profile), I'd be totally OK. I'd also be ok with a handful of different tools, all by the same team/project, with the same shared vision and interoperability in mind to begin with.
Eg: JDK + maven + junit + tomcat
Making these components pluggable is arguably how we get innovation (eg: yarn/pnpm, jest/vitest, etc)