The big question I always ask about these designs is "can the peripheral processor access arbitrary memory"... if so, then you need to worry about bugs in the fw blob possibly splattering something you care about... on a number of the more modern ARM SoCs, the peripherals sit behind IOMMUs, so the kernel has final say in what exactly the fw can interact with. Not sure how things work in this particular BCM SoC.
Obviously, a completely open driver where you can fiddle with any part of it beats the implementation running on an embedded core, but I'll take the embedded core any day of the week over having to have random proprietary binaries in userspace or (shudder) the kernel.
All I ask is that the architecture give the kernel a way to protect the apps processor and main memory from the dedicated cores. Debugging memory corruption issues originating from blackbox coprocessor firmware: very not fun.