This really depends. If someone is trying to operate with small user defined generic functions on a large array of user defined defined classes in Common Lisp in a tight loop (i.e. what Michael was doing) then performance is very very hard to recover.
Of course, performance claims about Common Lisp are very slippery because one can always say "well, __ implementation using ___ library can avoid ____ specific performance problem", but I think it's fair to say that in general, generic code and CLOS features can land you in very serious performance trouble quite quickly, especially if you're trying to make reasonably portable code.
in general if you are concerned with performance you will want the ability to "touch metal", which means digging into implementation-specific compiler details. this is something that sbcl is very good at providing
portable code is appropriate when the whole language can benefit from your library
Of course, performance claims about Common Lisp are very slippery because one can always say "well, __ implementation using ___ library can avoid ____ specific performance problem", but I think it's fair to say that in general, generic code and CLOS features can land you in very serious performance trouble quite quickly, especially if you're trying to make reasonably portable code.