That's correct. But understanding that string concatenation forms a monoid is quite nice, because it means that libraries can offer you this as an interface and you can choose the type you want to use.

Sorry for the wall of text, but I think to maybe help you understand why people (like me) like to work with it a bit more explicitly, I'll have to make it more concrete and give lots of examples. The good stuff comes at the end.

So let's say you have a list or array type. You want to aggregate all the things inside. Let me write pseudo code from here

   let balances = List(1, 4, 23, 7)
   let overallBalance = ???

How do you calculate that? Well it's simple - use a for-loop or call .reduce on it or maybe your language even has a builtin sum() function that works for lists of numbers right?

   let overallBalance = sum(balances)

Now what happens if you want to concatenate strings instead? Can you reuse sum()? Probably not - you will have to hope that your language / std lib has another function for that. Or you have to fall back to implementing it yourself.

Not so if monoids are explicitly supported. Because then, it will be exactly(!) the same function (which has been implemented only once) - no type-overloading or anything.

   let overallBalance = combineAll(balances)
   let concattenated = combineAll(listOfStrings)

Okay, seems a little bit helpful but also doesn't seem super readable, so I guess that's maybe not very convincing. But the reason why I personally love to work with monoids as an explicit concept is the thing that comes next.

Let's say you got bitten because you used plain numbers (or even proper money-types) for the balances but in the code at some point you mixed up two things and you added a balance to the users age (or something like that) because you used the wrong variable by accident.

You decide to make Balance an explicit type

    class Balance( private innerValue of type number/money )

So the code changes

   let balances = List(Balance(1), Balance(4), Balance(23), Balance(7))
   let overallBalance = sum(balances)

But the second line stops compiling. The std lib sum function doesn't support your custom balance class for obvious reasons. You will have to unwrap the inner values and then wrap them again (both for the sum() method or in your handwritten for-loop).

In case you use a duck-typed language where you can just "delegate" the plus-operation to the inner value: congratulations, you are already using monoids without calling it like that. Unfortunately, there is no protection against problems, such as that + might mean different things on different types and they can be used with sum() but cause unexpected results (read: bugs).

In case you use a language that has good supports for monoids, you essentially have to add just one line:

    a monoid exists for class Balance using Balance.innerValue

That's it. You can now do

   let balances = List(Balance(1), Balance(4), Balance(23), Balance(7))
   let overallBalance = combineAll(balances)

And, magically, "overallBalance" will be of type Balance and be the aggregated balance. In case you think that it can't work as easy as that, I'm happy to show you some runnable code in a concrete language that does exactly that. :)

On top of that, it does not end here.

Let's take it a step further. Let's say don't only have the account-balances of a single person (that would be the example above). You have that for multiple people.

So essentially, you've got

    let listOfBalances = List(
      List(Balance(1), Balance(4)),
      List(Balance(23), Balance(7)),
      List(),
      List(Balance(42)
    )

And you want to calculate the overall combined balance. Now it gets interesting. Even in a duck-typed language, you can't use sum() anymore, because the inner lists don't support that. You will have to to fall back to a manual two step process, such as

    sum(listOfBalances.map(balances => sum(balances)))

But with monoids it's different. Since we know how to combine balances in a monoidic way, we also automatically know how to do that for a list that contains balances. In fact, we can do so for any list that contains something that we know of how to combine it. That means, without any other code changes required, you can simply do

    let overallBalance = combineAll(combineAll(listOfBalances))

This is recursive and goes as far as you want. And it does not only work with lists, but also Maps and other structures. Imagine you have a map with keys that are strings and values that are of any type but constrained to be a monoid. E.g. Map("user1" -> Balance(3), "user2" -> Balance(5)). Or Map("user1" -> List(Balance(2), Balance(3), "user2" -> List(Balance(5))). Or even maps of maps.

Now if we have two of those and we know that the values are monoids, we can combine them as well, using again the same function, no matter what is inside. E.g.:

    let map1 = Map("user1" -> Balance(3), "user2" -> Balance(4))
    let map2 = Map("user2" -> Balance(5), "user3" -> Balance(6))
    let aggregated = combine(map1, map2)

And the result will be

    Map("user1" -> Balance(3), "user2" -> Balance(9), "user3" -> Balance(6))

This is such a powerful concept and makes a lot of things so convenient that I'm always crying when I work in a language that does not support it and I have to handroll all of my aggregations.

One note at the end: all of this can be absolutely typesafe in the sense that if you try to call combine/combineAll on something that isn't combinable (= is not a monoid) it will fail to compile and tell you so. This is not theory, I use this every day at work.