Hans is correct.
In more detail, there are some liabilities of the late-binding strategies that pervade Common Lisp. If you declaim a function to be inlined, then you are promising that you will never change it. While a very smart implementation could track all the other functions that have inlined that function, and automatically recompile them, I'm unaware of any implementation that has provided the mass of bookkeeping this would require.
A generic-function is unlike a regular function in that it has an implementation that is typically distributed across many top-level forms, and often distributed across many source files. This makes the bookkeeping all the more dificult.
Some may remember ultimately unsuccessful Apple's Newton project in the late 1990's. During part of that project they intended the major platform programming language to be Dylan, which was recognized as a Lisp derivative benefitting from the recent completion of ANSI CL standard but with a number of new ideas. (It was extremely disappointing that Apple eventually decided to use C syntax rather than Lisp, because that makes macros nearly impossible.) Dylan was ultimately unsuccessful -- mo mature implementations -- and abandoned in favor of C++.
But Dylan had one really great potential feature CL lacks: It has protocols for declaring a class tree of a gf to be sealed. That was a promise that these entities would never after be modified, which include extensions! Once a bunch of stuff has been sealed, a "block compiler" could in principle (and probably also in practice) walk over an entire application and do lots of inlining and degenerifying of function calls, without changing the semantics of a correctly-declared program. Sealing is something I would like to have seen added to CL, but machines are so fast these days that inlining and degenerifying aren't what the Lisp market is concerned about these days.