Might be a good idea to enable logging as well, it makes it a lot easier to debug your game and liaise with support if necessary. You can do this by calling FMOD::Debug_Initialize, passing in FMOD_DEBUG_LEVEL_LOG as the first argument for maximum logging.
Not sure what you mean by channel maps, are you asking why some examples use channels and others use event instances?
Off the top of my head, depends on whether you think you will have lots of objects with sound managed in the same way, or few objects with sounds managed in different ways. Having a generic sound manager that only requires an object’s transform lends itself better to the former because you will only need to create one sound manager class that can latch onto anything (as the UE integration does), whereas having specialized sound managers local to specific objects lends itself better to the latter because you will be able to have fine-grained control without needing to make many arbitrary sound manager specializations.
Probably a state machine that calls a looping event during the active state, and stops in the inactive state. There was some discussion about this recently using Unity bolt scripting which conveniently illustrate this concept at a high level.
Setting up sidechain compression in FMOD Studio is the usual way to go. Here is a video that explains the concept.
Please let me know if anything needs clarifying!