My take on why monoids seem to be thought of as concatenation in the Haskell community is that the other simple examples run into some difficulty with the way the type class system is set up. Specifically, the example you used requires a newtype wrapper, because the nats (ints really, we don't use nats much) are a monoid under both addition and multiplication. We don't have any better way of dealing with multiple instances, so we create a Sum newtype and a Product newtype. This adds enough friction that those instances seem to not get used all that much. Other examples of this are the Boolean monoid under conjunction or disjunction, and the monoid of endomorphisms under composition. Those instances all exist, but I rarely (if ever) see them used.
There are definitely some more general uses of the Monoid type class than concatenation that don't require newtypes, but they are slightly harder to understand, so they don't tend to get trotted out as examples. The best example I can think of is Ordering (LT | EQ | GT), which is a monoid in the sense of lexicographical ordering. You also have Function (a -> b) and Maybe b, which are each monoids when b is a monoid, but if b is a monoid under concatenation then those just look like concatenation too.
One other reason I think they're thought of as concatenation is that monoids under concatenation are extremely useful. The most common case is when appending things that are like strings. Strings are not performant, so for anything significant you want to use Text or ByteString. However, it's not uncommon to use Strings when you're first figuring things out. If you want to then switch over to Text and you used String appending (++), you'll have to find and replace every instance of that. If you instead used Monoid appending (<>), you can switch the types and everything will still work. Quite nice.
