Well of course there are ways to write reusable code without type classes. But let's say for the sake of argument that that's really what you want. You can in fact implement ad-hoc polymorphism, or something very close to it, without type classes. Type classes can be seen as a way to implicitly add a set of values to scope, but this can be done explicitly by using a record type. Consider (I'm guessing at syntax, I don't know elm):

    -- Monoid as a record type
    type Monoid a = {
      empty: a,
      append: a -> a -> a
    }

    -- Using this to make a generic concatenator 
    mconcat : Monoid a -> [a] -> a
    mconcat m = foldl m.append m.empty

    -- Instance of Monoid for strings
    MString : Monoid String
    MString = {
      empty = "",
      append = (++)
    }

    -- Instance for ints
    MInt : Monoid Int
    MInt = {
      empty = 0,
      append = (+)
    }

    -- Use the generic function
    unlines : [String] -> String
    unlines = mconcat MString . intercalate "\n"

You'll note here that the actual function signature for mconcat looks almost exactly like its Haskell counterpart, just that the Monoid instance is a regular argument like any other.

Of course the downside is that you have to pass in the instance argument to any "type class polymorphic" function, so you lose a bit of conciseness but not much in the way of expressiveness. And you actually gain a bit, because instances are explicit (for example, you could make an instance of Monoid Int which used 1 and (*) instead).

I'm not sure if this pattern is used anywhere in extant Elm code, but this is a common way to implement type classes under the hood in languages that support them, and the approach seems doable in elm.

Are you trying to say that in the 30 years of time between the discovery of Lisp and the discovery of typeclasses, no one wrote reusable code?