Mass production, which in software terms is really widespread reuse as in DBI or HTML::Parser, always benefits from loose coupling--externally.

But one of the greatest benefits of loose coupling in the external interface of a module, is that it allows the internals to be very tightly coupled whilst concealing the complexity of the implementation from the user.

Graphics Adapters were originally very tightly coupled to their processors. The graphics on the Atari and Amiga PCs that were so revolutionary in their time, used highly customised chipsets that worked in tight syncronisation with their cpus, and made the generalised, loose-coupled adapters in IBM compatible PCs look positively clunky by comparison. Now, the loose coupling in the latter shines, because it allows the like of Nvidea et al to produce internally highly tuned, complex and powerful cards with their own on-board, specialist processors, whilst maintaining loose compatibility with anything that talks to them via that same clunky interface defined way back when.

The problem with designing for loose coupling, as with most things, is where to draw the line. OO-doctrine will require you to use abstract interfaces within a module and between subcomponents of that module, as well as at the external interface. In many cases, that is a step too far. The overhead costs of loose coupling internally, can mean that the benefits of a well defined external interface are never truely realised, because the module is too slow for real world applications.

The trade-off when designing for loose-coupling is:

How likely is the subcomponent behind that interface to be reused in it's own right, rather than as a component of the larger system?

If the answer is "Not very likely", then it may well be better to eshew the loose coupling at that level, in order to realise the benefits, usually performance, to the overall system, derivable from tight coupling internal subcomponents.