"You shouldn't throw out Sass standards to achieve this"  agreed.

As to the other half, the whole point of structuring things like this is to imply a link between styles and markup where styles are coupled to markup.  I'm not sure how this implies a coupling between styles and code logic.

Any styling whose effective scope cannot be easily identified smells.  It cannot be changed or removed with confidence because it's difficult to determine exactly what effects any given change will have.  The more strictly CSS is coupled to specific instances of markup, the clearer it's scope is and the easier it is to manage.  When a piece of CSS is exactly coupled to a view file, it's scope is communicated absolutely and it can be changed with complete confidence.  When someone removes an old partial, to clean up now-unused CSS is the trivial job of deleting the file with the same name.

As to re-using blocks between projects, It _shouldn't_ affect that.  Once some styling is reused in multiple places it cannot be coupled to a partial anymore and must be made into a module.  Whether that module stays in the app or goes into the frontend toolkit is another question, and I suppose you could argue that all modules should be common across all apps.

All in all, this structure is designed to minimise amount of loosely scoped CSS and make life easier for everyone a couple of years down the line.