I considerd these methods are purely linked to the model . The controller triggers it, but the methods themselves make no reference to it. Actually, it would have been cleaner if the world.model.statistics was actually player.statistics (makes sense to me).
IMHO, that's a case of MVC vs SOLID (more precisely, the S of SOLID). I always favor SOLID which is the basis of all OOP best practices. MVC is way more flexible, and there are many interpretations (and variations) of it.
I think several controllers may have to check whether a Requirement is fulfilled or not. I could consider a RequirementsController, either as singleton or with static methods, but putting all object model manipulations in the controllers will lead to code fragmentation (harder to read : "Ok, I found this requirements class, but where the hell is the implementation of Requirement validation ?"), and rewrites (every controller checking requirements will need his own requirements checking method).

I think your extensive use of controllers is against OOP, making the code look more like functional programming than OOP. To me, in MVC, the controller is simply an orchestrator that defines which view methods should be called upon model-triggered events, as well as the opposite (view events triggers model methods). If you have a trivial 1:1 mapping between model and view (boolean to "led" for example), the controller is a simple proxy, abstracting the view and the model from each other.

All said, your code, your project, you're the BDFL, you decide, I'll abide !