The question is not _how_ to inline, it's _whether_ to do so at all. Inlining the wrong things can make performance worse. Because of this there's some heuristics that indicate things that are worth inlining. It is reasonable to question whether these heuristics could be improved, and even to offer improvements to GHC if you are so inclined. There's no magic "inline all the right things for optimal performance" algorithm, just a large and growing body of experience and test cases showing some of the things that work well and some of the things that don't. You are encouraged to add to it.
The thing about "more information" is related to how GHC implements cross-module inlining while also supporting separate compilation. There's a decision when compiling the definition of a function about whether it's worth including in the module's interface file. If it is so included then there's a second inlining decision made at each of its use sites. If it's not included in the interface then the calling modules just see an opaque function, which cannot be inlined as there is no more information about what to inline.