Programming

There's no point spending twice the time making something that corresponds 1:1 to code - unless the code is truly horrific, and then you've got bigger issues. One generally assumes people involved with a project will know or learn relevant languages.

It's more commonly used for things that are less obvious from the source itself - like "what's sent between the client and server in this handshake" or "what is the overall architecture of this part of the code"

Flowcharts may be a bit more common when studying algorithms in general

Edit; from your other comments, you seem to be talking about protocols, not algorithms. An algorithm is a set of steps to do something. A protocol is a description of how different systems interact such as in a chat application.

Most software is poorly documented. That applies to FOSS as much as to commercial projects.

Considering that reading source code can take a long time

You'll get faster over time, until reading code is faster than reading documentation, as code will always represent what's truly happening, while docs are frequently outdated.

In a language the user isn't familiar with

If you're not that familiar with the language, it's likely you won't be contributing to the project. Open source projects usually to have quite limited resources, so they tend to optimize docs and dev UX for people who are likely to contribute.

"algorithm" is a little too fine grained for what you describe. "software design patterns" is probably what you are looking for.

unfortunately, not all projects call out the patterns they employ.

The answer to this question is the same as for all documentation:

1. Because it's boring to write documentation
2. What is obvious and what needs to be explained is often not apparent for the person creating it
3. When time is limited then documentation is the first thing to be reduced
4. Not enough value is put on good documentation and the associated skill

But in the spirit of FOSS documentation is something that is actually an excellent thing for a person new the project to start contributing to. You need to understand the code anyway to be able to help with bugfixes / feature creation so might as well build reputation by improving on existing documentation by adding clarification and comments and wiki entries that would've aided in making it quicker for you to grasp something.