When I was a little less experienced than I am now I made similar mistakes. After you learn the basics of programming and move beyond writing mountains of if/else statements you see dramatic improvements in code quality as you "compress" your code. But a lot of people, myself included, mistake the cause for the improvements. It's not that high-entropy code is better.

A better goal would be minimizing the number of ideas someone needs to keep in their head as they read through a block of code. This means that breaking something into smaller functions isn't always helpful. Now you have to jump around and switch contexts. And when it comes time to change functions that are called in multiple places you will have to consider all of the contexts in which the function is called.

Something that's domain-agnostic, like an implementation of a basic functional tool (map, reduce, etc.) is pretty much free in terms of complexity cost. The reader will certainly already know exactly what the function does. The functions are well defined ideas that do not allow for addition of special cases to be added later. You won't add a branch inside of the implementation of map to handle an extra case if it is not sufficient for a new task. You'll just break down and write a for loop.

But something less well-defined won't be free.