Inconsistencies in the source file do not affect production worthiness in the moment, but they do affect maintainability down the line. If for instance your team wants to move to a new css preprocessor that's the next big thing in 10 years, a consistent style means you can programatically convert to the new syntax. Or maybe there's a tool that can help you write better css and detect where rules are unused -variable syntax will be sand in the gears for something like that. Mishmoshed syntax everywhere is a nightmare for programatic accessibility, though is excellent for simply trying things out.
I love stylus, don't get me wrong. I use it for all my projects - even in production. But if I were the head engineer of say, google.com, I wouldn't allow it in production for a codebase that large due to the potential for problems down the line.
I wouldn't pick Stylus for a new project, but you can use it with a linter like Stylint (https://github.com/SimenB/stylint) to enforce stricter conventions. Totally agree with you on the importance of consistency for maintainability (where it can be applied automatically with tools).
Clear and consistent code formatting guidelines (and ideally automatic formatting for this) is also great for reducing the thought required in formatting code you push while reducing noise and code formatting debates in code reviews.
I love stylus, don't get me wrong. I use it for all my projects - even in production. But if I were the head engineer of say, google.com, I wouldn't allow it in production for a codebase that large due to the potential for problems down the line.