I want to underline that fact that this stuff is not "read and move to the next chapter."

A lot of this kind of "machinery" in functional programming and category theory turns out to be essentially extremely abstract "superclasses" or "traits". In fact, many of them are too abstract to actually be defined in most programming languages. So they may appear as "design patterns" rather than actual definitions, if the language isn't quite expressive enough.

So to understand these ideas, you have to ask the questions:

1. Why this abstraction, and not a slightly different one?

2. What are some concrete examples of this abstraction? (Usually this feels like, "So, huh, familiar things X, Y and Z are all the same, viewed from this particular angle.")

3. What almost fits this abstraction, but not quite? And why?

4. Now that I see this pattern includes a whole bunch of interesting things, can I do anything useful with that?

A good example of (2) is realizing that futures, Rust's Result and Option, and Python's list/stream/etc compressions are almost the same thing, from a certain angle.

But it takes a while to collect all the related examples and to work through the connections carefully. The common patterns are usually really simple once you finally see them, which is part of the problem. They patterns are so abstract and cover so many things that it takes a while to work through the implications, and to decide if something is genuinely useful. Some very simple and widespread patterns will turn out to be boring, because they don't correspond to any problems you've ever seen.