What are the trade-offs between "separating module interface/implementation unit in a different source file" and using "private module fragment"

The tradeoff is pretty obvious based on the limitations. A private module fragment (PMF) can only appear in a primary module interface unit, and there can be no other module units that contribute to a module that has a PMF. This means that the primary downside of using a PMF is that you're restricted to putting everything for a module in a single file.

The performance of module importing, broadly speaking, is not based on how much stuff is in a module. As such, putting a lot of stuff into a module is a pretty good idea. But putting all of those things in a single file can be long-winded and difficult to maintain. As libraries get bigger, splitting them into multiple files is usually better for organization.

The PMF construct is mainly for making it easy to distribute a library that provides module and non-module builds. The main code lives in (mostly) regular headers and source files, which are used to build the non-module version. For the module version, you have a single module unit. In the global fragment, you #include any headers that your interface headers use that are not part of your library (standard library headers, dependent libraries, etc). In that module unit's purview, you #include all of the interface headers within a big export{} block. The private module fragment can #include all of the .cpp files used to compile the library, so that the compiler can just build that one module file and get everything.