I haven't noticed it being a problem in Haskell. Most of Haskell's weird operators are either uncommon enough so that everybody uses parentheses with them (such as bitwise (.|.) and (.&.) and so on), common enough that you don't forget (but (&&) and (||) are the two I always forget, and occasionally some people don't use parentheses with them), or weird and common but it's very hard to use them incorrectly without getting a compile error ((.) and ($) and (>>=) and (<$>) and (<*>) and (++) and (:) and (&&&) and so on). I don't think most of the operators in the last list would be usable without static type checking.

In particular, operators like ($) and (.) are hugely beneficial and the latter's existence is one of the main reasons people like Haskell's syntax.

I appreciate both, honestly. Lisp achieves a great deal through purity of syntax, but that sort of thing was never Haskell's goal. Personally, I almost never think about how precedences compare; instead you learn a Haskell coding style that support the syntactic tricks allowed by operator precedence. A pretty common one goes something like this:

  forM [1..] $ \n -> do
    a <- monadicAction1 n
    b <- monadicAction2 a
    return b

Which is sort of ugly from a Lisp point of view, but I think it's a great trick enabled by having $ be an ultra-low precedence sequencing combinator. It looks like a Ruby block almost, but has zero extra syntax and very clear semantics.