Actually that is not a IM problem, but a shell (BASH) problem.
Shell will separate all words separated by any white-space as separate arguments.
As such when you have
-crop 100 x 100 +0+0
the shell parses that into 5 arguments, where IM is expecting only 2 arguments... -crop and its single required geometry-style argument.
IM probably was producing errors like: unable to open image "x"
that should be the give away IM is not getting what it expects as it is seeing 'x' as a filename and not as part of the -crop argument.
The other effect (other than read errors) is that
-crop 100 (what IM is seeing) is equivalent to
-crop 100x0 or cut the image into multiple (tiled) 100 pixel columns!!!! Which is probably NOT what you want!
Removing the spaces causes the shell to treat the 100x100 as a single argument (two total).
The other solution is use quotes so as to tell the shell to include the spaces in the argument
EG:
-crop '100 x 100 +0+0'
IM does understand spaces and will handle an argument containing spaces (ignoring them as appropriate). A long time ago this wasn't the case, which is why that line in the reference manual
still exists.
ASIDE... IM Internals...
Geometry arguments are a special argument that has a commonly used (and complex) parser. It basically allows a user to specify a single argument containing up to 5 floating point values (though most operators only use integers). These are typically of the form: WxH+X+Y but can also be in the forms of +X+Y or A/B/C or A,B,C,D,E, due to operator requirements. On top of that it reports if special 'flag' characters are present (any of %@^!<> ), but it only the characters presence, not where they were found. IM for example does not remember is that % was attached to a specific number, just that it was present.
If more than 5 numbers are needed, a different argument-style The floating point list, is used, though at the moment these are generally parsed by individual arguments. For example -sparse-color can substitute colors for some floating point values, though they also become floating point values when passed into the core library. Other operators may understand percents, or not. That makes non-geometry arguments a highly variable, depending on the operator parsing it.
In future there is a push to allow the use of percent escapes in ALL arguments, including geometry arguments, but 'percent' handling (is it a percent escape, or a percent flag?) is a bit of a problem.
See IM Examples, Future Development,
Setting arguments from in memory images and/or other settings
http://www.imagemagick.org/Usage/bugs/future/#settings