To me thats not ideal, I'd rather a less expensive check that i don't have to do every frame, in that if Health reaches 0 or PowerInput no longer gets power, movement will then stop working.

Be very, very careful here. It's not that you can't change your logic to be event-driven, but event-driven systems can get really complex and difficult to debug.

For example, while both PowerInput and Health are individually able to disable Movement, neither of them is individually able to enable it. Just because the power is restored doesn't mean that the health still isn't 0. This inherently requires some logic that spans across the three components in order to make that combined evaluation, which goes against the very outset you're starting from here (I agree with the posted comment that decoupling doesn't mean zero dependency and that you may be setting the bar too high).

It might not matter when your game only deals with the act of disabling cameras and never being able to re-enable them, but it is a very important consideration when you start applying this pattern at large.

Checking the value of an in-memory variable is not a significant performance hit in any way. There is likely no actual performance bottleneck to address here, no matter how many security camera objects are running in your level. Unless there is some underlying IO operation here, which I very much doubt, I would suggest you don't try to prematurely optimize this at all.

To me thats not ideal, I'd rather a less expensive check that i don't have to do every frame, in that if Health reaches 0 or PowerInput no longer gets power, movement will then stop working.

Be very, very careful here. It's not that you can't change your logic to be event-driven, but event-driven systems can get really complex and difficult to debug. In any sizeable codebase, you quickly lose the overview because events obfuscate the flow of your logic at runtime.

For example, while both PowerInput and Health are individually able to disable Movement, neither of them is individually able to enable it. Just because the power is restored doesn't mean that the health still isn't 0. This inherently requires some logic that spans across the three components in order to make that combined evaluation, which goes against the very outset you're starting from here (I agree with the posted comment that decoupling doesn't mean zero dependency and that you may be setting the bar too high).

It might not matter when your game only deals with the act of disabling cameras and never being able to re-enable them, but it is a very important consideration when you start applying this pattern at large.

Checking the value of an in-memory variable is not a significant performance hit in any way. There is likely no actual performance bottleneck to address here, no matter how many security camera objects are running in your level. Unless there is some underlying IO operation here, which I very much doubt, I would suggest you don't try to prematurely optimize this at all.