Ummm... because it's a database, and anytime you'd want to use an enum, you'd be more likely to look it up in a table anyway?

Probably because it's not in the ANSI-SQL standard. But that doesn't really answer your question, because now you need to know why it's not in the ANSI-SQL standard. Even if that's not a rhetorical question, I doubt anyone could give you a straight answer except for the designeers of the ANSI-SQL standard.

Really, instead of using enums, why don't you just use a VARCHAR() field?

I use a VARCHAR(4) field for a lot of the places I would normally use enums in other programming languages.

I use a lookup table like so:

CREATE TABLE tblStatusCodes
(
Code VARCHAR(4)
Desc VARCHAR(30)
CONSTRAINT PK_tblStatusCodes PRIMARY KEY CLUSTERED (StatusCode)
)

Now, in the table with actual user data in it is like so:
CREATE TABLE tblAccounts
(
...
StatusCode VARCHAR(4)
...
)

The tblAccounts.StatusCode column is a foreign key to tblStatusCodes

If you set up the referential integrity rules, this prevents spelling errors of a code when data is being inserted and updated. Also the tblStatusCodes table can be joined in for access to the Desc column whenever you need a human readable translation of whatever the code represents, say in the your app's forms or reports.