One advantage is that multiple languages can target the same IR and benefit from the same optimizations. Another is that more development effort is focused on one IR instead of spreading it across all of the languages targeting it.

One possible disadvantage, you can't gain information by automatically converting code to another representation, but you could potentially lose information that would be relevant to an optimization. I don't know of any practical examples of this happening with LLVM, but I believe Java's type erasure carries a very slight penalty.

Another possible disadvantage is if you have a language designed to be compiled extremely fast, then adding an intermediate step could slow it down unacceptably.

I'll add to mcbit's excellent description that there's also advantages in verification. Passes on a simple, intermediate language can more easily be equivalence-checked by symbolic (eg KLEE) or formal (eg VeLLVM) methods to ensure the transformations didn't break the program somehow. So, you get piles of people contributing optimizations plus potential improvements in verifying they work.

https://klee.github.io/

http://www.pgbovine.net/PhD-memoir/ucklee-cav-2011.pdf

https://www.cis.upenn.edu/~stevez/vellvm/

The advantage is you are tied to the IR and not the compiler (if the language designs it's own IR), the disadvantage is the same as the compiler optimizes via passes on the IR. What would be needed is a way to 'hold' optimizations on the IR so that you aren't playing a game of will-it-optimize (or worse will-it-not).