Draw a box. Write something in the box. Draw an arrow.
There. You're using UML.
Yes, the guys who spec out UML -- and many of the practitioners -- think of it as a do-all, end-all language of goodness and OOP.
But read your quote again. It's a visual language. A purpose of a language is to communicate. Who are you communicating with? Some folks think you're communicating with the computer itself, and their UML looks that way. But the language communicates to other people. You can be as loose or as detailed as you like, as long as you are communicating. The language spec simply provides you a range of depth in formality to use depending on your circumstances.
I teach this, I use this, and I've coded both OOP and FP for years. I think I know what the hell I'm talking about. Yes, according to the authors it can be used with all major OO systems, but that's a far cry from meaning the two are inseparable. It can also be used with railroad design, or industrial lighting systems.
I get really tired of dogmatism in programming. The idea that you can quote an authority as somebody who somehow controls the everyday practical uses of a thing. It's almost like we think of standards bodies as the programmers and people as the little machines that run the standards. UML is a tool. Pick it up. Use it. Understand what the tool is used for -- in a practical sense, not in a technical one. The definition of the tool is in the hands of the wielder, not some standards group. They just write specs. No one tool can do everything, and the directions that came with the tool were probably written by folks who see the entire world in terms of their tool.
If you're not designing your functional structures in some fashion -- including just in your head -- then I don't want to be maintaining your code. Whether or not you draw pretty pictures to do that or not is only important if you need to communicate that design to somebody else or sort it out in your head. And that's not even getting into all the other uses of UML -- component modeling, network diagramming, etc -- that have nothing at all to do with programming. If you think of UML artifacts as directly relating to OOP, go talk to a business domain modeler who uses UML, or a network analyst, or a BA.
It's a modeling language, not a coding language. You use it when you need to model. Modeling can help you in all kinds of situations. Or not. Draw a box. The rest of the discussion is around whether you need to draw the box or not, and it's so dependent on particular situations it's not germane to this conversation. Simple as that.