Not having to worry about language feature support across different compilers is a big win. See https://bugs.chromium.org/p/libyuv/issues/detail?id=685 for one specific example of why using Clang can have benefits over MSVC (TL;DR: 64-bit MSVC doesn't support inline assembly). Clang was already being used to compile this little part of Chrome on Win64.
Switching to Clang also allows the use of Clang-based sanitizers and fuzzing, which improves the security of Chrome.
IIRC, Microsoft wants you to use intrinsics because it plays better with their register coloring and code reordering optimizations.
Unless there's an instruction you need that doesn't have an intrinsic or you're writing something like a spin lock where instruction ordering is critical and a compiler barrier for some reason is not sufficient, there's no reason to ever write assembly.
Your code won't be appreciably faster than if you tuned it in the compiler, and after a few years the compiler will integrate new instructions while your assembly just gets stale.
> Unless there's an instruction you need that doesn't have an intrinsic or you're writing something like a spin lock where instruction ordering is critical and a compiler barrier for some reason is not sufficient, there's no reason to ever write assembly.
So there are reasons to write code in assembly language.
There are few reasons to use assembly, and even fewer to use inline assembly
Using CPUID is one, using very specific vector instructions another (but you can do most of this using intrinsics) and it's better if they get their own .s file
Switching to Clang also allows the use of Clang-based sanitizers and fuzzing, which improves the security of Chrome.