Returning SCALAR for GLOBs would definitely be incorrect. GLOBs contain scalars, not the other way around.

Not exactly. A glob is really a kind of a scalar value, just like an integer or a string is.

(Update 3:) The confusion comes from this: a glob has certain fields: SCALAR, ARRAY, HASH, GLOB (not really a field...), etc. This does not imply that there is a separate data type for each, that it can point to. It's just pure coincidence that perl happens to have scalar, array, hash, and code as the four most important data types, and these are the four most well-known elements of a glob too.

Let's discuss this more (but I might be wrong, as I don't know perl internals as much as some other monks here, so correct me please).

It is clear, that the four most-well known elements of a glob are distinct data types: *foo{SCALAR} is a reference to a scalar, *foo{ARRAY} is a ref to an array, *foo{HASH} is a ref to a hash, and *foo{CODE} is a ref to a code. If $x is a ref to a scalar for exmaple, you can not make it become a ref to an array without changing $x itself.

On the other hand, *FOO{GLOB} (which is really the same as *FOO) is really a reference to a scalar, and you can see it is because of this:

$x = \$y; $y = *_; print $x; $y = 5; print $x;
[download]

GLOB(0x813bda0)
SCALAR(0x813bda0)
[download]

(Update: minor reformatting of the last few paragraphs.)

I've left out IO handles, FORMATs, (Update 4:) Regexps, and packages from this discussion because I don't really know them well. IO handles is a fifth kind of data type I think, but I'm not sure.

(A bit off-topic:) Also note that I these four (or more) types are not the types an expression can have. That's something very different. The value of a perl expression is a scalar, a list, or nothing depending on its run-time context (which depends on the callers of the expression, but not the expression itself). It's just plain wrong that scalar and list contexts are sometimes associated with scalar and array data types. For example, the scalar glob element *FOO{SCALAR} is magically linked with $FOO, which returns the content of the scalar field of *FOO in scalar context, or a list of a single element (the contents of the scalar field) in list context. Things are not so simple with *FOO{ARRAY} which has four constructs linked to it: @FOO, $#FOO, $FOO{EXPR}, @FOO{EXPR}, \@FOO which more or less return values related to *FOO{ARRAY}. Note that \@FOO is not just the \ operator applied to @FOO. The \ operator normally returns a list of the references of the elements of the list it gets as argument (ie a list of scalar refs), or a single scalar ref in scalar context. (Most of these constructs can also be used in lvalue context, such as \$FOO{EXPR}, push @CODE, EXPR, $FOO{EXPR} = EXPR etc, which makes things even more complicated.) What shows that these are indeed associated with the*FOO{ARRAY} array reference is that you can put any array reference instead of FOO in any of the above construcs (but you have to add a brace unless the expression yielding the reference starts with $). The same goes with hashes and subroutines, the special expressions associated with them are %FOO, $FOO{EXPR}, @FOO{EXPR}, and \%FOO with hashes; and FOO(EXPR), &FOO(EXPR), &FOO, \&FOO, FOO EXPR (if declared), FOO INDIROB EXPR (if prototyped so), FOO {STMTS} EXPR (if prototyped so); (I might have missed some).

Update: I forgot to answer this one:

LVALUE has a better case for utlity than REF, because this is how you find out if something *is* an lvalue. (I think? Do you know another way?) For references, you already have the ref builtin itself. See my comment to

No. Actually, most (or all?) scalar references are lvalues. For exmple $x = \$y; is an lvalue reference as you can say $$x = 5;.

(Update 3: trying to add some more context to the second and third paragraph to make it cleaner.)

A glob is certainly not a kind of a scalar value!

The meaning of scalar is something that holds a single value. A string (seen as an object) is a single value. An array, such as an array of characters of a string, is not a single value, because it has different "slots" for different pieces of information. A glob has fields, as you say yourself, so it is not a scalar, either.

In regard to LVALUE, it means something more specific than that.

perl -l
$s = '123456789';
$r = \substr $s, 0, 1;
print ref $r; $$r = "x";
print $s

LVALUE
x23456789
[download]

I understand what's going on, but I don't know this feature well enough to comment on its general use.

LVALUE is used internally for the 'magic' used with substr, vec, pos, keys, etc. when you use them as lvalues in an assignment. It holds (in addition to typical scalar data) a pointer to the Sv* that it can modify and what part to modify.
PerlGuts Illustrated has a lot of information on how Sv*'s are layed out. In reguards to your original question is shows that SvRV (a struture that holds only a reference to another Sv*) is smaller than SvPV, SvPVIV, and SvPVNV, which are the 3 that I'm guessing are considered 'SCALAR' by ref. So 'REF' might indicate that the underlying structure is to small to hold a full scalar value, and would need to be upgraded to a SvPV of better to hold a non reference value. I don't know that any of that information would be of any use to Perl code, and perl handles all that on the C level so 'REF' may be only informative, or entirely redundant, depending on your viewpoint. (but as others have noted ref is less than totaly useful it self as it stands now)
Disclaimer: I've only recently started looking at the internals of perl, I could be totaly off mark on any of this.