Ah, the suckless philosophy - making everything as terse, austere and featureless as possible in the name of 'simplicity'. It's a wonder so few people want to adopt it.
To get a further glimpse into that philosophy check this out: http://harmful.cat-v.org/software/ and recoil in horror as literally everything you've ever used (and sometimes even liked) is deemed harmful. There also used to be some more ahem 'controversial' content which I assume was removed to get with the current times.
It is an interesting exercise in minimalism and understanding as many parts of the system as possible, but I wouldn't know why you'd want that too be your daily driver and I can think better alternatives from people who don't name their machines after nazi bunkers and liberally use alt-right dogwhistles. Linux from scratch or Alpine for instance.
what I never understood about the philosophy is their definition of simplicity. For example all their terminal software and so on basically requires configuration in C and every time you change one thing you have to recompile it, and everything is one big mush of code. And when you want to patch something you have to apply diffs in the right order and pray. That's not simple, that's spaghetti code.
Modularity and proper configs produce more lines of code, but it's actually simpler in human terms.
There is no suckless "philosophy". The official page explaining it makes a few solid points about simplicity vs. complexity [0] but for the most part its just thinly-veiled programmer rage and elitism. This is reinforced by the community's purity tests which include enforcing arbitrary limits on the lines of code in a given project (about as dumb and wrong as dogmatically asserting that more lines of code in a commit is better - complexity is about abstraction). That's not even getting into the racial purity tests [1].
Aside from that, suckless software just sucks. Software is more than just source code; it's the user experience, it's the community, it's what comes out of that software. The Blender source code certainly wouldn't fulfill the suckless vision (in sofar as one even exists) and yet it's infinitely more important and useful than any piece of suckless software. Showing off your minimalist desktop on /r/unixporn or /g/ is fun and all but eventually you're going to want to do real work with your computer and realize how much time you've wasted recompiling C code to make basic configuration changes.
Simplicity of implementation vs simplicity of use (as well as simplicity for a beginner vs simplicity for an advanced user). A suckless tool (lets say st) is a simpler implementation. Easier to port, less likely to have bugs, less likely to have security issues, etc. Features are added under patches, as it's easier to add a feature then take one out.
If it helps think of it as how much of programming is dedicated to reducing complexity, breaking things down, abstracting to core components, etc.
I do use a lot of suckless utilities but from personally experience running Alpine as a daily driver for ~3 months I can't in good conscience recommend a MUSL distribution, despite the fact that in my opinion Alpine does everything else right.
I was thinking of the possibility of bad interactions between multiple patches. But maybe in practice that's not actually a problem. It was just what came to mind when I read that bit.
"stali is a static linux distribution based on the original pre-2010 plans of the suckless.org project, however since 2018 it became independent from suckless.org and is maintained by Anselm solely."
We all know: Stalin brutally optimizes. Iirc it is still one of the faster scheme compilers. Sure, Chez will probably run more stable, but I for numeric code or when the full program optimization can work it's magic in ways that other scheme compilers can't it produces faster code than all other compilers.
Last time i checked it was the most capable at optimizing type inference in the presence of mutation. Where most other schemes just did boxing, Stalin produced nice and fast code.
Are the resource overheads of a dynamically linked system really that important in 2020, considering that Linux has always been famous for being able to run on low spec hardware?
Musl has its problems too. I've stopped using alpine as a docker base image to avoid having to sink time into fixing occasionally compatibility issues (pip, Java)
Dynamic linking overhead was not that significant in the late 1980s on 25MHz 68030 and 68040 systems. Only in an overwhelmingly large system will that fraction of a fraction of a percent matter significantly.
To get a further glimpse into that philosophy check this out: http://harmful.cat-v.org/software/ and recoil in horror as literally everything you've ever used (and sometimes even liked) is deemed harmful. There also used to be some more ahem 'controversial' content which I assume was removed to get with the current times.