In general, CMO is a significant performance win. But (as with most optimizations) there can be corner cases where you see a degradation.
The critical problem with CMO is code size. Therefore the CMO which is enabled by default is much more conservative than the "aggressive" CMO, which must be explicitly enabled with -cross-module-optimization.
impact on compilation times
We didn't see any significant impact on compilation times. Especially with the default CMO which has only a relatively small impact on size/complexity in the optimization pipeline.
ways to limit cross-module inlining to a select group of modules within a package
The compiler option -disable-cmo disables the default CMO.
can cross-module inlining take place across package boundaries
yes
is there ever a reason to manually wrap/specialize to “hide” generics in the post-5.7 world?
It really depends. CMO makes it less likely that generic APIs will have a negative performance impact. But it still can happen (CMO is an optimization based on heuristics).