Ah I forgot they did that. The pawn calls “CreatePlayerInputComponent()” which sets up its custom InputComponent. The InputComponent reference is inherited from the AActor class.
I believe, on possession and unpossession, they have put in fail-safes to ensure input binds only work for possessed pawns. To be on the safe side, you can call EnableInput and DisableInput for the pawn when possessing or unpossessing, respectively.
I am not sure why the docs state you may run into problems but it may be stating that in case you don’t use Enable/DisableInput. Someone with more knowledge on that may need to respond to that one but, if it seems to be working fine, it could be that the documentation is just stating that so that you don’t rely on their fail-safes to automatically ensure things go smoothly.
If you aren’t looking for custom input handling in the way I do it and you like this approach then this is definitely a viable straight-forward solution.
The major use for my custom input system is that it stores input states for each device and has the ability to determine if input is activated through holding, tapping or while held instead of storing states and duplicate functionality in specific pawns. If you don’t need any behaviour like that then using pawns the way you have tested should be the simplest approach for you.