That's not "DLL Hell," it's an attempt to alleviate it.

And it's a really good one. It's easy to ensure that all the system software or all of a particular package (e.g. Office) uses the same version of a DLL, but approximately impossible to ensure that all third-party software is always refreshed to use precisely the version that's loaded on a particular machine (where that version can very based on Windows release, service pack deployment, etc.).

This is especially a problem in enterprise deployments where there may be a variety of spottily maintained internal and third-party applications loaded on a machine. Having to choose between refreshing every single one of them or throwing the unrefreshed ones out is an impractical choice. Thus DLL versioning.

Avoid resulting problems by either maintaining your apps in a way that allows them to all use the same build of a DLL or simply by running as few apps as possible to minimize library loading in general, duplicate or otherwise.

The article talks about size on disk. Not how it gets loaded in memory.

Well, multiple versions of code being loaded means that there are fewer common pages to share across processes. However I think it is the right tradeoff to make.