Scheme has historically striven to be a minimal, complete,
consistent, multiparadigm language.  That means the standards
have been very short relative to other languages, covering
relatively few concepts and structures but making sure that
the semantics of each concept are mathematically as simple
as possible, and that those concepts and structures are
sufficient to synthesize pretty much anything and lend themselves
to programming in pretty much any style.

As a result, it's been ideal for teaching computer science - and
I want to emphasize the word 'science', as opposed to 'trade'.
'engineering' is somewhere inbetween.  The trade of programming
means studying individual languages and systems and tools and
libraries and coding standards and protocols and gaining some
proficiency in using them.  The science of programming is about
how each of these things are designed, the math behind them, and
what kind of design and mathematical tradeoffs are involved in
different ways of doing things.

When you're studying computer science, you don't want to waste
too much time teaching the students a language.  So you want a
language that smart students accustomed to rigorous thought can
literally pick up in a couple of days.  And scheme has been
that language.  When you're studying object orientation and
how OO systems should be designed, you want a base language
that contains the facilities necessary to roll your own object
orientation extensions, so you can try out several different
types of OO in the course of a single semester.  And scheme
has served that need as well.  When you want to talk about
functional, OO, and procedural programming (and if you're
completist, even unification programming) you need a language
that easily or with the addition of a library or two lends
itself to all three.  Scheme works great for that.

The fact is that Scheme doesn't have a lot of readymade things
that other languages have.  Instead, it has the facilities to
easily build them. And that means it lets you freely experiment
with different designs or different *ways* of building them,
or even design individual programs using different facilities
depending on what fits the individual problem best.

But this extreme flexibility tends to play bloody hell with
interoperability.  Typical scheme programs contain
infrastructure code that virtually everything "interesting"
about the program depends on.  If you want to reuse code,
you have to do some serious work to make sure it can get
the kind of object-oriented functionality it wants, and
the version of the TCP stack code that has the particular
functions and argument orders that it requires, and the version
of the CGI library that provides CGI variables with the variable
names it expects in the scope it expects, the particular module
system that it depends on, the "wrappers" for common functions
that it expects, etc, etc, and etc.

And if you attempt to reuse code from several different projects,
as is typically the case with opensource programming, you learn
the true name of pain.  Many of these extensions conflict with
each other, requiring namespace control.  But many of the
module systems granting namespace control also conflict with
one another.  And you start by trying to sort it out, and
if you're like me, end by throwing a bunch of stuff out the
window and coding it from scratch - again. Because scheme makes
it very easy to code from scratch and very hard to integrate
code that diverse people relying on diverse libraries wrote.

Such systemic conflict is also in the heritage of Common Lisp,
but Common Lisp took a different route.  Where scheme did not
standardize that which was controversial or multiply-defined
and instead included sufficient "good stuff" to build it whichever
way you wanted from scratch, Common Lisp undertook standardization
with the express purpose of supporting (or at least easily porting
to the new standard) and permitting interoperability of a vast
body of legacy code, and actively locked a lot of the "good stuff"
up (such that you now have to jump through serious hoops if you
want to redefine any standardized function, and rolling your own
control constructs with general reified continuations is simply out
of the question) to prevent people from re-creating the quagmire.

The result is that the Common Lisp standard adopted wholesale
the structures and designs of several different lisp systems
which no longer really exist in the wild.  There is duplication
of purpose in many standard functions, with subtle differences
and variations made necessary by different design decisions in
the ancestral lisp systems.   On the plus side, this gives you
a "standard" function that's a drop-in replacement for nearly
any function in the ancestral lisp systems, standardizes an exact
semantics for each, and saves you having to implement such
things yourself.  On the minus side, Common Lisp is a relatively
huge language, and most students are not going to pick it up
in a couple of days.  Also, because its design is relatively
fixed, you have a single object system and that means it's
extra painful to experiment with multiple different other object
systems.  Likewise module systems, etc.  Also, the mathematics
and semantics of Common Lisp are more complex and sometimes
opaque, with subtleties about referencing the "data" value or
the "function" value in expected and unexpected ways seriously
getting in your way if you try to do (or analyze rigorously)
pure functional programming.

Like all larger structures, it has to be more rigid.  Thus there
is far less room in Common Lisp to experiment than there is in
Scheme, and so while it has served the needs of software engineers
and tradesmen rather well, it hasn't been as kind for designers
and scientists, who need to experiment. One of the things that
makes scheme *hugely* flexible, and which computer scientists
love to use in experiments, is general reified continuations. The
facility simply can't exist in Common Lisp because it would
enable code that would actively subvert the semantics of, or
unexpectedly expose implementation details of, a lot of common
libraries and implementation strategies.

But CL has largely achieved its goal of providing interoperability
for a vast quantity of old lisp code and providing a stable
platform for writing new code.  And the duplication of purpose
in many of its functions has translated into the ability to
express certain kinds of subtle differences simply and precisely.
And because those different versions of functions exist with
standardized names, first you don't have to implement the
particular version of them your code requires, and second you
won't usually get subtle name conflicts when porting or
integrating code.  Both of these greatly lower the mental overhead
of integrating code from diverse sources into a single program.