It would make no sense for "application object components" to be accessed via the cache (regardless of the syntax used to access the cache).
You're right it wouldnt. That was a mis-wording. But: the command object should access application object resources via $self->app->$resource
not the current way $self->$resource
might be a slot in the application object or a slot in the command object.
And: the cache is a resource that the command requires the application to implement and provide. You mentioned uploading Commands to CPAN separately. What sort of interface should a command have with the application? Should the application boldly and indiscriminately put any numbers of slots in the command? Or should there be one well-defined interface via one method between command and object, namely $self->app
This code (in CLI::Framework::Application):
# Share session data with command...
# (init() method may have populated global session data in cache
# for use by all commands)
$command->set_cache( $app->cache );
Should raise a red flag, because over time as various commands require various application-level resources, you are going to have to manually keep coding the wedding between application and object here with additional slot injection instead of one well-defined interface via one method between command and object, namely $self->app
Just think of what you're doing... let's just say there are 3, as you put it, "instance variables kept in both Application and Command. ", cache1, db_handle, interprocess_communication.
Now, you have 4 commands. With your approach, you install all 3 of these accessors in all 4 commands, for a total of 12 accessors for sharing data between application and command.
With my approach, only the app accessor is shared between application and command, for a total of 4 accessors. As the number of shared resources grow, your "accessor bloat" grows linearly. My "bloat" is constant at 1.