The short answer is that I don’t know yet, at least not for sure. This exact set of problems is part of what I’ll be exploring when we make the golden path for the “walking simulator,” likely shortly after 5.0 release. I can tell you that what I think I’ll recommend is having specially-marked (by name or other mechanism) geometry in the glTF that the loading code can then find and turn into physics impostors. This will allow complete control of the collision system directly from the DCC tools used to produce the assets and remove the difficulties of trying to hand-craft physics entities in Babylon itself. However, I’ve not actually tried this, and it will likely be a few months before I get a chance to do so in the context of the “walking simulator” golden path. That’s definitely on the radar, though!
Regarding using an ArcRotateCamera with physics collisions, my honest recommendation would be to not attempt it. I don’t really know what the desired behavior for such an interaction would be, but generally speaking I wouldn’t advocate trying to mix physics (which tries to control the behavior of objects) with Babylon’s utility cameras (which have highly specialized behaviors all of their own). If all you want to do is keep the camera centered on a character, you could probably use an ArcRotateCamera for that, but I wouldn’t try to add physics to it. If you want to make it avoid clipping through walls, your best bet is probably a per-frame raycast from the character toward the camera to determine the correct distance. If your environment is fully robust physics-wise (i.e., absolutely everything has an imposter) then that raycast might be done within the physics system; but if your physics environment is more sparse (i.e., impostors elided on high ceilings, etc. that players can’t collide with but cameras might), then it might be more appropriate to use Babylon’s built-in mesh-based collision system for that specific raycast.
Hope this helps, and best of luck!