Size. Using styles like this lead to a small decrease in page size, which over time on a very high traffic site leads to a notable bandwidth savings.

... or at least, that was the argument. In practice, most teams didn't adopt it unless mandated from above; because it sucks to use, has an infinitesimal decrease in individual page load time, and the bandwidth savings certainly don't outweigh the lost developer time.

But hey, all you gotta do is convince some VP that your niche approach is the right one, and you'll get some adoption in a large company like Yahoo.

Where have you heard that argument? That is absolutely bonkers. Why didn't they just use css as intended and collect all these inline styles into generic classes? Or turn on gzip-compression?

I worked in an org at Yahoo that required all development to use Atomic, and that was essentially the reasoning as presented. The Atomic authors put a lot of effort [1] put into proving the size point, enough that it was pretty difficult to argue with. The stylistic issues were sort of swept aside; less size == faster page loads == more revenue.

If you believe the size argument, and care more about short term revenue over developer productivity or happiness, it makes sense, I guess.

[1] https://acss.io/frequently-asked-questions.html#what-are-the...

> Why didn't they just use css as intended

Too many engineers and not enough actual problems.

I recently botched a badly written site with loads of inline styles in to something responsive, you can override inline styles. It's not pretty, but it works:

  *[style*="text-align:justify"]{ 
       text-align: left !important;
  }

> but what on earth would I want to override a class called "P(20px)" to do instead? :)

lol maybe you might want to express the sizes in another base /s

    .P(20px) {
      font-size: 10px; // 20px in base 5 is 10px in base 10
    }