I've used singular going on 27 years now, initially because that is what I first read in white papers, best practices and the first databases I inherited. And as I gained more experience it simply made sense to me from a modeling, consistency and brevity perspective all mentioned previously in this thread.

A pluralist commonly argues that a Customer table is a table of Customers, therefore it should be named Customers to reflect that collection. However, I look at it as a singular object with properties. And the notion of plurality can be countered when looking at the collection more colloquially. For example, we call it a Newspaper Stand, not a Newspapers Stand; Or Airplane Hangar, not an Airplanes Hangar; Or Book Store, not Books Store, etc.

The reserved word argument has merit against singularity, but I try to avoid reserved words at all costs and I treat it as a necessary trade-off to pluralizing every table with an S, ES or IES.

I also name my foreign keys with both the parent and child table names. A foreign key named fk_CustomerOrder is more natural and makes more sense than fk_CustomersOrders. But that may just be personal preference for me.

Regarding prefixes on objects, I don't prefix tables, but have no problem with tbl or t_ prefixes as long as all tables have them. I do put a v_ prefix for all views as I want any code to be distinguished between the two. I do this not just for my own benefit, but for the benefit of anyone taking over support of a database I've created. Anyone who has assumed development or maintenance of a legacy database with hundreds of tables and views knows the importance and relief when views are prefixed and identified as such.