When you're estimating the maintainability of a codebase over time and identifing modules that are overly complex (i.e., buggy), these kinds of tools are invaluable.
That said, if your functions are pure functions, they won't contribute much to overall complexity. It's a much different situation from having a do_the_thing() method that does some mutability magic.
The lightbulb moment for me came when I got a job working on a compiler and had to start maintaining some long files with some very large functions. Being able to read linearly through a long, fairly flat function easily beats hopping hither and tither trying to remember which bit does what and piece the whole thing together.
The real complexity in code isn't from the code itself, of course; it's in the data it works with, how it modifies the data, and how far apart bits of code that may touch the same bit of data in interleaved sequences are.
It's also one of the reasons I prefer reading recursive algorithms that use pattern matching, or in a pinch, switch statements, over and above dynamic dispatch from polymorphic references. If code doesn't need to be open to extension, it's much better off exposing an enum or some other easily flat-switched thing, than implementing a recursive algorithm in almost any other form.
For example, at the company I work for, we check code complexity every time someone pushes to certain branches in our repositories, and mark the build as unstable if the score is too high. In that case, the only acceptable solution is refactoring; all builds must be stable before the task associated with the change can be considered complete.
It's not reasonable to run it once a month or longer---by then we've moved on, context and focus have been lost, and refactoring is considerably more expensive (both for development and because it has to go back through QA) than if it were done immediately.
[1] https://wiki.jenkins-ci.org/display/JENKINS/Checkstyle+Plugi...