Hey @RustyToms,
I’ll take a stab at this issue, but I’d like to first specifically address the desire to “future proof” your code (“should we deprecate the actions hash”, “can you envision the actions hash being deprecated”).
Future proofing
As written down in our FAQ about future proofing your application, that is why we have the release process we have, from the six week cycle, to the deprecation cadence and Guides, and LTS releases, our hope is that you can smoothly upgrade your application by addressing deprecations as they come.
So in that sense, I would advise to keep doing business as usual. The Ember.js Guides are also maintained by the learning team, which tries to make sure it reflects the currently advised practices.
Why the actions hash
The tl;dr is: namespacing.
For what now are mostly historial reasons, the API surface of Ember.Component is quite wide.
What this means in practice is that when people were creating a destroy() action to destroy some item in a list, for example, and they overrode the built-in one, leading to all sorts of zany memory leaks and things not being torn down 
You asked, should we ever use the actions hash? Yeah, I content that you still should always use it. Is it possible not to use the actions hash? Also yes, but you will have to provide additional education on the pitballs, like which action names you can’t use and such.
The future
I want to mention this, not as motivation to avoid the current API (which should be obvious by now ;P) but to show that we took this into consideration when designing the newer minimal API available in Glimmer components.
Despite the need for RFCs to officialise the API, as well as RFCs for their integration into Emberjs proper, you can look at Glimmerjs components to have an idea of our current proposal.
Notice that they are a new Component implementation, with several important differences in semantics, syntax (ES6 classes, decorators, and such), and API, providing what we think is useful and flexible API that doesn’t get in your way.
When/If these components land in Emberjs after the RFC process, it won’t mean the deprecation of current components. And if/when current Ember components get deprecated, you will get plenty of notice, and a detailed migration path.
Too many words, give me the juice
You should continue using the actions hash, as that API avoids overriding important methods in the Ember.Component base class.