What you have in the scheme side of the world is that everybody
has developed their own idiosyncratic library of functions and
syntax -- usually, for maximum portability between implementations,
in the simple language defined by R5RS.  As someone who hacks
compilers in scheme, I've got a huge library of string functions
and regular-expression stuff -- I say

(load (string-append *basedir* "libs/rdstringlib.scm"))

at the beginning of the file that implements a lexer, for example,
and suddenly I've got all the string functionality I personally
will want for this particular program.  And my string library is
heavily optimized for compiler work.  Someone else will have a
different string library, heavily optimized for the particular
task s/he works on, say report generation.  Our two string
libraries may have no definitions in common at all, but we don't
care.  

And that is the fundamental difference.  Anybody who uses scheme
for serious work has a set of libraries that extend the language
and define all kinds of syntax and stuff.  The actual programs
we write are usually as short as CL programs, because we use just
as much library functionality, but the libraries "belong to the
programmer and not to the language" - I use the same string library
in fifty programs, I don't count it as part of the effort of
writing any single one of them.  Heck, people who are annoyed by
tail-recursion being the only way to express iteration even define
LOOP as syntax.  But every user of scheme extends the language
in his or her own idiosyncratic direction, to perfectly match
his or her own programming style and task set.

Common Lisp, by contrast, extends the language for you,
provides all the libraries so you have to learn them instead
of implementing them.  Which is fine, but the library functions
provided by common lisp may not be a perfect fit with your own
particular programming style, tasks, and mode of thinking.  
That's what you get when you buy a house; it's not necessarily
the house you would have built, but it's a nice house and it
works for you.

Anyway, what I see is that scheme programmers are capable of
doing a heck of a lot as individuals, and are very happy with
the personally-customized language they each work with.  But
they tend not to work together on large projects because of
the cognitive overhead of learning each other's personally-
customized languages, which may have different or conflicting
definitions.

Common Lisp programmers, by contrast, have a lot of standard
libraries and tend to forgive or ignore some small things that
may not fit perfectly with their personal style.  But they do
work together on large projects, because they all have the same
set of language extensions and they can read each other's code.  

And so, I would give this advice; if you tend to work on things
alone, and you have a good design sense about libraries to
suit your tasks, start with scheme.  If you want to write code
in a team with more than two other people, or you don't want
to design and build your libraries for your task area, start
with CL.

One thing about scheme is that while it's a very easy language
to create an interpreter for, and even reasonably easy to
create a compiler for, it's very hard to create a really *good*
compiler for.  Every implementation seems to have different
strengths, which can be a pain but which can get you into a
lot of different environments, some of which are too small
for CL.

Different tasks will require different compilers: to name a
few, bytecode interpreters for tiny embeddable environments,
JIT bytecode compilers for CGI scripts where compilation time
is important, optimizing machine-code compilers for all-out
speed on general-purpose systems where compilation time is a
nonissue, and there are compilers that produce even faster code
if you don't need the full numeric tower for a particular task.  
So keep your personal libraries portable and you can migrate
between implementations at need.