If the controller is in it's own file it will work. The reason is because it needs to have the path set for the appName and at the time the Ext.define is fired for your controller, the path isn't setup because Ext.app.Application hasn't been created either.
I guess it does because dependencies are not only relevant as a means of loading file resources, they also affect the class loading (=creation) order I would assume. That is probably more true for a class that defines dependencies via 'requires' than it is for dependencies defined via 'uses' or plain 'Ext.require' statements.
However, this assumption is rather based on logical conclusions derived from how other class dependency loading schemes work than it is based on knowledge of the actual implementation of Ext.ClassManager
When doing a build, it of course will look at all the classes required and will build them into 1 file. You then include that file in the production index.html (or whatever you use) and when that file is loaded by the browser the classes are defined. They are now ready to have instances created.
While it might seem obvious that this is not going to work, it could as well have been supported assuming that classes will only be available in 'Ext.onReady'. Classes with missing dependencies could be queued until the dependency is available. A missing dependency would cause a failure only if not resolved until 'documentReady'.
However, I don't want to imply that this is a desired feature. I was merely openly thinking about the behavior of Ext.ClassManager in a production environment.