Perl 6 approach to OO seems different than CLOS's (Smalltalk-ish???).
The Object Apocalypse covers some of the rationale for the Perl 6 OO system design. The Apocalypses were published around a decade ago but Perl 6 as it is today remains very close to the system Larry described then. That said, all of the Design docs were primarily addressed to folk who knew Perl 5 and wanted to help implement Perl 6, and the Object Apocalypse isn't a CLOS vs Perl 6 comparison, so...
I last spent significant time playing with CLOS in the 90s. Reading through A Brief Guide to CLOS as a refresher and noting, in no particular order, possibly consequential apparent differences if I'm not mistaken (I may have made mistakes in the following which I'm writing in somewhat of a hurry):
What CLOS calls "methods" are ordinary functions that support multiple dispatch. They float outside of CL classes. They don't get access to a `self`. Perl 6 has the same feature but uses the term "subs" (short for "subroutines") or more specifically "multi subs". The equivalent of a CLOS 'generic function' is a "proto sub".
Perl 6 also has what it calls "methods" or more specifically "multi methods". These functions (or "routines" in Perl 6 parlance) are typically defined as part of classes and they do have access to `self`.
Multiple dispatch in CLOS is always late bound (resolved at run time). Perl 6 supports compile time checking and resolution (if only zero or one leading candidate matches) as well as late bound multiple dispatch (if multiple leading candidates match or the leading candidate is unknown at compile time). See also my SO answer to a recent Perl 6 question.
While Perl 6 provides good FP support, the language parser and compiler itself is built using OO features and the MOP and language braids (as yet not officially documented and clearly on the move right now) let userland code control compilation and the syntax and semantics of Perl 6 itself. Aiui CL leaves this to macros, which, while awesomely powerful in their own ways (see 007 for the Perl 6 project attempting to outdo that awesomeness), aren't nearly as user friendly and scalable/interoperable across the community of users.
Perl 6 supports multiple dispatch against all types, not just objects, eg native ints and floats etc. out of the box. It sounds like that gets more complicated in CLOS. Also, individual values, like CLOS. Perl 6 adds arbitrary `where` clauses to the mix too. (And I'll throw in a mention here of autothreading too, which is akin to a parallel computation dispatcher thrown into the function dispatch mix.)
Unlike CLOS, Perl 6 encapsulates attribute access.
Like CLOS, Perl 6 supports arbitrary routine combination schemes as part of routine dispatch (though it doesn't build a before/around/after scheme into the standard language). In fact you can specify a dispatch scheme per object! (Yes, much of this stuff I'm piling up in this comment is major overkill for 99.9% of users' programs. Fortunately the language is carefully designed in such a way that 99.9% of users need never care about any of this because the language remains easy for easy stuff and fairly easy even for complex stuff.)
Like CLOS, Perl 6 supports multiple inheritance but the primary OO composition tool is roles which are a generalization of what Smalltalk calls "traits".
Like CLOS, Perl 6 supports changing the structure/nature of objects on the fly. See but and does.
CLOS is "not a prototype language" according to this CLOS guide I'm reading whereas Perl 6 specifically supports both class-based and prototype-based OO.
Like CLOS (well, like the MOP extension to CLOS), Perl 6 has a powerful MOP that makes it easy to create new object-systems by extending or changing the provided Perl 6 functionality and have these systems interoperate at the class/object level. Thus Perl 6 has foreign object system adapters that let you load classes and objects from other langs and sub-class those foreign classes and instantiate those foreign objects as if they were Perl 6 classes/objects (and, if the foreign language is sufficiently adaptable, the other way around too). Naturally the most mature of these adapters is the one for Perl 5 (example) but there's a growing list.
Perl 6 takes its MOP down to the metal via 6model, unifying Perl 6 objects, foreign object systems, MoarVM's base services, and C structs.
I'm glad I've now gotten to the end of the guide. ;)
All of these goodies come with some obvious "short term" costs for ordinary users: poor performance and poor documentation. The Rakudo Perl 6 compiler has been speeding up 2x to 4x each year for the last 7 years but, compared to many other languages, including Perl 5, it can still be shockingly fat and slow for a lot of stuff. Similarly, the doc keeps on improving, and books have finally begun to arrive again this year (the last printed books were published way prematurely about 10 years ago), but expect limited or non-existent coverage of some of the features I listed above for a while yet, perhaps several years.
But the vision remains a language that starts with a base, like Perl 5 did in 1994, and then evolves from there to who knows where, but this time with much cleaner and more cleanly extensible syntax and semantics and an architecture built to sustain 100 years of evolution.