Another perspective is of course that of the embedded developer, a camp I can count myself to. In embedded software, it's not uncommon to have exactly one targ

Another perspective is of course that of the embedded developer, a camp I can count myself to. In embedded software, it's not uncommon to have exactly one target for the software (commonly called "the target"). Sometimes the target changes due to components being end-of-lifed or so, but it's rare and slow. In those situations, I have found intrinsics to be very helpful since they allow you to reason and talk about the software at a higher level (C is, after all, higher than assembly) and without making sure all developers on a team understand the inline assembly syntax. :) It is still good practice to check the resulting code, especially as, if you're using intrinsics, chances are you're often thinking more or less in assembly, but you can do that once and be pretty sure you're getting the desired result. The resulting code is of course also more portable, which can be helpful when you want to e.g. automate tests of code without external hardware dependencies such as data structures, utility functions, and so on.