As JacquesB writes, not everybody agrees with Robert C. Martin's "Clean Code".
The open source projects that you found to be "violating" the principles you expected are likely to simply have other principles.
I happen to oversee several code bases that adhere very much to Robert C. Martin's principles. However, I do not really claim that they are right, I can only say they work well for us - and that "us" is in fact a combination of at least
- the scope and architecture of our products,
- the target market / customer expectations,
- how long the products are maintained,
- the development methodology we use,
- the organizational structure of our company and
- our developers' habits, opinions, and past experience.
Basically, this boils down to: each team (be it a company, a department or an open source project) is unique. They will have different priorities and different viewpoints, and of course they will make different tradeoffs. These tradeoffs, and the code style they result in, are largely a matter of taste and cannot be proven "wrong" or "right". The teams can only say "we do this because it works for us" or "we should change this because it doesn't work for us".
That said, I believe that to be able to successfully maintain large codebases over years, each team should agree on a set of code conventions they think are suitable for the aspects given above. That may mean adopting practices by Robert C. Martin, by another author, or inventing their own; it may mean writing them down formally or documenting them "by example". But they should exist.
Consider the practice of "splitting code from a long method into several private methods".
Robert C. Martin says that this style allows for limiting the contents of each method to one level of abstraction - as a simplified example, a public method would probably only consist of calls to private methods like
transformDataToJson(...) and finally
sendJsonToClient(...), and these methods would have the implementation details.
- Some people like this because readers can get a quick overview of the high-level steps and can choose which details they want to read about.
- Some people dislike it because when you want to know all the details, you have to jump around in the class to follow along the execution flow (this is what JacquesB likely refers to when he writes about adding complexity).
The lesson is: all of them are right, because they are entitled to have an opinion.