This is a terrible misinterpretation of the article. It's not even tangentially related to hard-coding styles into HTML. Attribute models retain the ability to abstract style away from the HTML. Take the example used in the article, am-Button. Using the AM approach, you retain the ability to update the font-color, size, base styling in one place in a separate block of code (css, scss, whatevs). The styles are by no means scattered into multiple locations.
Certainly having a custom attribute that bundles multiple styles is novel.
...but having single attributes for color, font size and base styling is what attribute styles in early html were.
I think its disingenuous to suggest this is fundamentally different because these are custom style attributes (am-font) instead of hard coded style attributes (color).
The point is that presentation and data should be distinct in markup, and this use of custom attributes muddles things.
I can easily imagine some css framework providing css attribute classes that get used just like the old html style attributes, with all the same markup clutter and maintenance issues.
oh, want to change a style? now you have to change the markup attribute instead of the style sheet <--- this is why multiple display classes (btn--big) and custom attributes are fundamentally an anti-pattern.
Markup should be tagged with meaning attributes (btn--buy) and the styling done via stylesheets.
