The Clang change isn't a problem unless you can prove that it breaks a userland API/ABI (go ahead and prove me wrong, I doubt you can), that's what the stability in FreeBSD is all about and not about whether the tools used to build the programs are this version or that version.
Well for me I have to audit every compiler change, as need predictable behaviours in binaries. I got round this by using a specific version of a compiler from the ports tree instead of base compiler, but now the ports tree maintainers have started removing compilers that are not EOL upstream. Which makes it hard to rely on a compiler version in the ports tree as well, because the removal of compilers is now unpredictable and not in line with support policies upstream anymore.
Compiler development tends to be ahead of other software development, so a compiler gets released, and then there is a time lag for software developers to catch up and make their software work properly with that compiler, but if the OS is always on the latest bleeding edge compiler you dont get that 'matured' advantage.
Now if as you said the only concern is userland code, then perhaps that concern needs to be widened a bit, I know in the past the base compiler had to be stable on all ports as well.
I am looking at this from a LTS perspective, whilst FreeBSD seems to be gradually moving more and more to a rapid development model, other OS's have done the same but tend to have alternative policies in place for LTS user's as well.
