Hi!
The advice on the wiki is a bit out of date. These days, nine out of ten lispers agree that neither asdf-install, common-lisp-controller, nor Debian/Ubuntu-packaged lisp implementations should be used by anyone, at any time, for any purpose.
Why not go all the way and stop using Lisp altogether? There is no need for either asdf-install, common-lisp-controller or any packaged Lisp implementation if people stopped using those weird niche languages and started to use only C or Java software.
McCLIM itself should certainly be checked out from CVS (or a git mirror) rather than using asdf-install, because the last released version of McCLIM is quite old.
How come noone created a newer release? People shouldn't have to bother with stuf like CVS or Git, just to give a piece of software a try.
CLC, foisted upon unwitting victims by the Debian lisp packages, may not be intrinsically broken, but few people use it, fewer understand it, and it has earned a reputation for breaking things and causing headaches while offering no real benefit to most users.
Maybe you haven't looked into the common-lisp-controller enough to see what advantages it had. Try to install an application which uses McCLIM on 100 computers which can be used by a hundred or so different users. Then you find and fix a serious bug. Now try to update all installations...
Debian nor CLC are perfect (far from it in fact). But they still solve a number of problems faced by many people.
Some background: Swank is the backend half of SLIME, written in CL and loaded into your lisp process, which emacs talks to over a socket. It contains several functions which are useful to McCLIM for doing things which can't be implemented portably, and as it's been ported to every CL of interest and virtually everyone can be expected to already have it on their machines, it makes a handy compatibility layer.
CLC is a strange thing which, as I understand it, is used by the Debian CL packages for its ability to compile systems to FASLs and copy those to /usr where any user will be able to load them, so that each user isn't forced to compile everything themselves (and deal with the problem of not having write permission to /usr where the source code is installed). You can imagine how such an arrangement might not appeal to someone who wants the option of easily hacking on any and all components in their lisp environment, and as such most "upstream" hackers, so to speak, reject the CLC-based environment and install everything from source, rendering them unable to help when buggy interactions involving CLC crop up. :)
CLC allows system wide installation of libraries in source form, without preventing people from installing (and using) their own versions. The FASLs are compiled and per user ID. So CLC allows people to use common stuff while at the same time allowing people to use their own versions.
The biggest advantage of CLC is that it allows Lisp applications to be easily installed and tried. Nowadays people expect to be able to apt-get install any given application to just try it. If it doesn't work, then it is easy to remove. If it is too much hassle to install a Lisp application, then people will simply look for an alternative.
Many Lispers feel that Lisp deserves to be more successful than it is. But in order to be successful, Lisp systems need to meet such user expectations. The Debian Lisp package maintainers do their best to accomplish that. The result isn't perfect. But then, what is?
The version of SLIME provided by your Linux distribution appears to have been modified with the expectation that CLC will always be loaded before attempting to load Swank. This must hold true for however they've arranged SLIME to work, but not for the (admittedly uncommon) case of CL software that wants to load Swank independently. Loading CLC manually before attempting to load McCLIM may well fix the issue, but I don't know how to do that.
In theory the CLC will be integrated when the Lisp system is installed using apt-get install. The post-install script takes care of that. It will load CLC, and then write a Lisp image to the file system which is then loaded when the user starts the Lisp environment.
Groetjes, Peter.