We use linters as part of our CI process. So actually "tests" fail if code is not within standards of rubocop or coffee lint.
Personally I prefer this over cluttering the PR process.
Codelinters are imho less about "style" than about best practices. And many exist for good reason other just for uniformity. Both is usually important enough to enforce it.
The point of contention on this is if you are doing something approximating continuous deployment. In that scenario, the tests and build are part of operations, since they are prerequisites to being able to ship code. As such, in an emergency scenario, you do not want to be in a situation where time to recovery is impacted by someone committing a hotfix that has improper whitespace, etc. In the best case, you end up spending additional time having to to 'sign off' on the broken build being just due to the linter (which also introduces a real risk in a high stakes scenario, in that you are shipping a red build and now have another place for human error to creep in) or in the worst case, the system blocks deploys until a commit is pushed to undo the whitespace problem.
I'm not sure I agree -- having an alternate process for deployments in emergency scenarios is just asking for all kinds of trouble. It should be a well oiled machine that is consistent. If running the tests is part of the process, it should always be part of the process, otherwise you introduce additional complexity in trying to understand the potential outcomes of the system in unique scenarios. If the tests are slow that they gunk up the works, then the tests need to be fixed and the process changed. (Perhaps a large suite which runs nightly over less critical code, and a tight suite for mission critical code that runs pre-deploy.)
Guard will first execute the rspec tests, and only if those pass it will execute rubocop. This way you don't have rubocop immediatelly complaning if you make a style violation and can focus on making the code work first. Once you are done with that you will still nagged about style before you commit your code.
Our tests take < 10secs and after implementing a commit worth of changes (I would say ours are comparatively small) there are usually less than 3 style violations piled up.
Personally I prefer this over cluttering the PR process.
Codelinters are imho less about "style" than about best practices. And many exist for good reason other just for uniformity. Both is usually important enough to enforce it.