Should we put units of measurements in attribute names?

This is why the Mars Climate Orbiter crashed into the surface at 350 meters/sec when it was planned to only handle 350 ft/sec (or something like that).

Although "Never say 'Never' or 'Always'" is, in general, a good rule of thumb, here I will bend my rule and say I think you should "always" make it clear what units a numeric value is in.

If you have a consistent UOM for things, then your DBA's policy is OK.

For example, if timespans are ALWAYS in minutes, etc.

If the UOM could change, then you should store it in another column, alongside the qty.

That said, I tend to side with you on this. Clarity trumps most things, including this. I'd rather see DurationMinutes than Duration and have to guess what the UOM is.

Yes. You should.

The key, as @[Charles Bretana] pointed out, is legibility and that the other users of your table or developers following you know what you're using.

I would absolutely involve the units/measurement in a field name - in my business you can't guess what you'll find from the context or name: a field entitled MarketValue - is that in millions, thousands or units? US Dollars, Euros, pounds, $CURRENCY? Is that value a percentage, a ratio? Absolute or relative? Daily, monthly, calendar year, financial year? That timestamp, what time zone is it?

Your first, last and only task when providing data is to ensure that it isn't used incorrectly because the consumer wasn't able to find out enough about it. As developers, throwing "Metre", "USD", "GMT", "Percent" or whatever into a field name isn't the least bit smelly.

There are enormous smells that need resolving before the tiny whiff of field naming needs standardising.