A bit of background information:
The (ANSI) SQL standard requires that non-quoted identifiers are stored in all uppercase in the system catalogs and that non-quoted identifiers are case-insensitive.
According to the standard the following non-quoted identifiers reference the same object (e.g. a table): FOOBAR, foobar, FooBar (and all would have been stored as FOOBAR in the system catalogs).
The following quoted identifiers reference 3 different objects: "FOOBAR", "foobar", "FooBar".
Nearly all DBMS comply at least with the requirement that non-quoted identifiers are case insensitive. Except for MySQL and SQL Server as far as I know - both can be configured to be case-sensitive even for non-quoted identifiers. I'm not sure what the default behaviour of SQL Server is though (as Damien pointed out in his comment, this depends on the collation being used for SQL Server).
MySQL is even more confusing as its behaviour depends on the combination of several configuration settings, the storage engine and the filesystem. All other DBMS I know are consistent regarding their behaviour across all platforms and installations.
PostgreSQL complies with the case-sensitivity but it folds everything to lowercase.
So given these rules, I think that the "traditional" naming convention using underscores stems from the fact that object names are stored in uppercase. The only way to get "readable" names is to separate important parts of the name with underscores.
SQL Server is even more non-standard as it is case-preserving (similar to the way NTFS under Windows works) so it does not fold the names to anything. So it does not change the case of the name when it's stored in the system catalog (but it is by default case insensitive). For that reason you will find people working in a Microsoft environment using CamelCase more often then e.g. in an Oracle environment.
