The compiler can optimize the layout of the basic blocks according to its beliefs (or hints) on the branch probabilities, but it won't move a code path to a separate function. I don't know if this could be done in compliance with the standard, but I haven't seen any compiler do it.
EDIT: I stand corrected, looks like GCC 4.9 can do it (http://goo.gl/amM4Et). Still, it didn't do it when I needed it :)
The link is helpful for background, but is it really useful to tell a programmer who is worried about i-cache contention to be guided by an automatic profiler rather than forcing the compiler to do what they want and then profiling that? I'm intrigued --- what prompts you to give this advice? It's the opposite of my instinct. Have you personally experienced issues with this?
Programmers are horrible at guessing branch prediction. It's a famous truism. And the only thing worse than guessing the branch prediction wrong would be moving the code farther away then adding a jump to it and back.
The next level of mistake is gathering the profile data from the unit tests. (Hey! Free Input!) Ugh.
Hardcoding "Case 5: is most often" in a library also bit me. If you're giving me the source, let me guide the paths, thanks. Maybe you use Case 5, maybe my code doesn't. (And I just stepped through Clang doing the exact right thing on a switch statement with inlining.)
I think you should have stated upfront that you were asking library-writers not to do that, because it's hard to guess actual branching profiles there. I don't think your advice apply that much to an application writer.
The article doesn't give any specific situations for doing this (apart from the example of an uncommon error case). You could indeed be doing this specifically from the result of looking at the profiler and then reading the assembly code output of a hotspot.
http://llvm.org/docs/BranchWeightMetadata.html