I don't know if I'd call that "inference" so much as coercion, precedence and propagation. The exciting thing about Haskell type classes is precisely the integration with the type system and its modified HM type inference -- if you don't think the Haskell type system is cool, you probably won't be impressed much by its fairly elegant support for an abstraction that lets you overload operators, perform multidispatch, enforce contracts, and define the very laws of mathematics.
Perhaps if you don't know Haskell, you should learn Haskell to understand what the article is saying.
I already know Hindley-Milner type inference, and I do know Haskell well enough to understand typeclasses, monads, etc.
I also believe that type inference is of limited practical application at scale. On a local level, internal to a module or function, it can make a lot of sense, but it's at risk of underspecification at the module interface level. For example, when you modify function bodies, you may inadvertently add more constraints to an inferred type (e.g. use an operator or function defined on a typeclass not previously brought in), and consequently break clients of the module.
This is definitely something that any interface author must deal with and is very closely related to the more OO-specific skill of "good interface design". It is important to include in an interface those types and type constraints that effectively and efficiently describe your problem domain.
OCaml (and potentially Haskell, though I haven't used this feature in Haskell) ameliorates this problem by giving the programmer the facility to specify (or generate and edit based on inference) module signatures that are then checked against. With this approach, I would argue that type inference actually makes your large-scale code more robust and easier to modify than without it due to the automatic verification of module signature. If you inadvertently introduce extra type constraints to your module's interface, the type-checker will tell you and save you from releasing a module that is incompatible with previous versions of the same module.
Without type inference, you're either annotating types everywhere (looking at you Java...) or waiting until runtime (or production!) to find out you've made an error (e.g. perl, python, ruby and on and on).
I really don't see how type inference and its associated program analysis and verification is anything but good.
Perhaps if you don't know Haskell, you should learn Haskell to understand what the article is saying.
Edit: This might help: http://www.haskell.org/tutorial/classes.html