you already said in your first post that you can't understand it.
I'm not a C programmer, so it would probably personally take me days, maybe weeks to fully grok 5K SLOC of C. Still, it is potentially possible if I made the effort, unlike with other programs, like you say.
It's a testament to the quality of the original C code that I was able to configure and use st and other suckless tools with my limited experience. An experienced C developer would probably find it a breeze.
I don't because I haven't needed to. Understanding just a few hundred lines has been enough for my needs.
When your main goal to just get on with solving your actual problems, these are the same thing.
Then I had a look around their issue tracker, and noticed others complained about this too[1]. And the dismissive and defensive response from the author just rubbed me the wrong way.
I've looked before and not found anything, but it's a niche thing on an already niche thing.
You're ignoring the part where the tools are often a fraction of the size and complexity of similar tools. I can go through a 5K SLOC program and understand it relatively quickly, even if I'm unfamiliar with the programming language or APIs. I can't do the same for programs 10 or 100x that size. The code is also well structured and documented IME, so changing it is not that difficult.
In practice, once you configure the program to your liking, you rarely have to recompile it again. Like I said, I'm using a 5 year old st binary that still works exactly how I want it to.
Maintaining a set of patches is usually not a major problem either. The patches are often small, and conflicts are rare, but easily fixable. Again, in my experience, which will likely be different from yours. Our requirements for how we want the software to work will naturally be different.
The madness you describe to me sounds like a feature. It intentionally makes it difficult to add a bunch of functionality to the software, which is also what keeps it simple.