Seems to me you've got a large number of people involved, and someone's trying to enforce some sort of consistency/standards so people can look quickly at a query (especially complex ones) and know what is what.
As long as the naming style is consistent from table to table, you'll be fine. So if a field is named ProductID, and everyone knows that ProductID reflects to the ID field on the Product table, you'll be fine. But if people start using the ID nomenclature and it's not for a foreign key, you'll have problems. Or if the field is ProductID in one table and Product_ID in another (not a major problem, but consistency...)
The only noticable benefit to using more verbose names is you won't have to alias like fieldnames on complex joins (ex Product.Name and Category.Name)
(oh, and I would never use Product.ProductName in a query. It would either be Product.Name or ProductName. If you've got ProductName in two different tables, then you've most likely got a problem with your nameing conventions)