When the debug function of the clang module is enabled, clang generates debug information for all types contained in any modules that your code imports each in its own section of debug information, and then all other debug information can use the types that come from this module, pointing to this section of the module is in debugging information.
When clang module debugging is disabled, each compilation unit (.c, .m or .swift file) will receive a copy of any types that it uses and will refer to them locally.
Therefore, enabling this "on" can reduce the size of debugging information for large projects.
In addition, since debugging information can be quite large, in the case of "off", the compiler performs some tricks to keep the debugging size manageable. For example, clang only emits used types into debugging information, so if there is a type from some module that no one in your program uses, you will not get debugging information for this type. This is not a big problem in general, because if you never use any type in your code, you are unlikely to use it in your debugging. But sometimes it can cause problems.
It also does not generate signature information for functions that your program uses, but does not define. That's why you have to throw return types into expressions in the "print" command that you don't need to do in your code.
OTOH, when it is "on", since the compiler knows that it only needs to generate this information once, it can be more complete about what it emits.
For Objective-C, you can work around any missing function types / signatures that come from the modules you use by running:
(lldb) expr @import "FrameworkWhoseTypesOrSignaturesYouWant"
at the beginning of a debugging session.