Very few people ever even attempt to write "lean software". The definition is a little nebulous, but "software without bloat" is a good one. This means that you have few dependencies, and the ones you have themselves have few dependencies, for a starter. But right there you have the first problem, which is that dependencies grow stronger with the number of users, and the number of users grows with applicability, hence the rise of dependencies that no-one uses more than 20% of, but everyone uses a different 20%. Even if you do tree-shaking or something so that you at least don't pass on the complexity you're not using, it still doesn't feel lean, because you're cognitively bloated, so to speak. Then, if you rewrite the library (because extracting your 20% is going to be very painful) you can make it simple and small, but no-one is going to use it but you and so it will remain weak, tightly coupled to the one project that uses it, because it doesn't offer the breadth of features people need.
The other reason software bloat persists is because knowing enough about the runtime of your software to even be offended by the presence of bloat is exceedingly rare. Repetitious and pointless tasks abound in modern software, where work is done at one layer and then thrown away and redone by another, repeated N times. But to even know about this requires that you understand your runtime and what its doing in your case, and in our industry, ignorance is (economic) bliss, where "go along get along" is richly rewarded and any aesthetic or moral objection to how things are done is harshly punished.
Strong and real social and economic forces drive bloat and punish the individual that would combat it. Which is why those who make the (at some level, doomed) attempt to fight bloat deserve at least our respect and some honor, since they will not only not receive thanks, they will be actively attacked by those who (correctly) perceive their work as a challenge to the status quo, and hence dangerous, unwanted, and a target.