IMO, the most important parts are to document the actual intent of the code. The contract of what is being documented. Sure, it’s only so useful in perfectly written code, but NO code is perfect, and few will come through later with full context already learned.
It makes it sooo mich easier to know what is intended behavior and what is an unchecked edge case or an unexpected problem. If it’s a complicated thing with a lot of fallout, good documentation can save hours of manually lining up consequences and checking through them for sanity.
You might say, “but that’s indication of bad code!”. No. Not really. Consequences easily extend past immediate code doing things as trivial as saving data to the database without filtering, or having a publicly available service. Even perfectly coded things come up with vulnerabilities all the time due to underlying security issues. It’s always great to have an immediate confirmation of what’s supposed to happen whether it’s immediate code or some library with a new quirk in a new version.
IMO, “One app/library/etc does one thing only” is a rather ignorant form of wisdom about encapsulation, anyways.
Encapsulation is important regardless of how many disparate tasks a library handles. Doing one thing with one thing is a pretty good rule of thumb to get close to good results, but it is FAR from a golden standard, and serves to drag people away from the finer nuances of encapsulation.
The ONLY time it is a hard and fast rule is at the individual function level. A single function ideally should have one task to accomplish, even if that task has side effects.
I’m sure there are cross-dependency issues on an OS level that makes it a bit wiser to do for wide, cross-cutting system tasks, but to make it an absolute rule smacks of wisdom gone awry.