Monoids are very simple objects, and you don't need to use category theory to define them.
Monads might be a more meaty example. But I'm not sure if knowing CT makes it easier to use monads in a programming context.
Sure, monoids are trivial, because they are, but once you're in the categorical setting you can begin to talk about the category of monoids, monoid homomorphisms and so on.
This isn't to say that CT is the answer, but I'm pointing out that it provides a way to understand more complicated concepts.
Functors are trivial, but if you take their fixpoint you get ADTs. Monoids are trivial, but if you apply them to the category of endofunctor you derive monads, and so on.
That's kind of the point.
> "Perhaps the purpose of categorical algebra is to show that which is trivial is trivially trivial." That is, category theory aids in making the softer bits of mathematics look utterly natural and obvious, so that one can more easily isolate the harder nuggets and attack them with abandon ... This is a tremendous service that category theory provides"
https://mathoverflow.net/questions/28788/nontrivial-theorems...
In isolation applications of category theory to programming are going to be trivial, typically. Category theory gives a language and framework for extracting trivialities so one can "attack the harder nuggets" without distraction.
Well, in the case of functor it's not terribly interesting, but here's an example. A functor F has the property F g . F h = F (g . h), so this means that if you were writing
you could write instead, (in Haskell the compiler optimizes it anyway) but if your compiler actually traversed the list twice, now it traverses the list once.I could list other things like how monoids, monads, etc. can help make programs more efficient (monoids allow exponentiation with squaring) or structure programs better (monads allow composition of partial/stateful/exceptional functions).