My personal opinion is that’s just “art for the art’s sake”. A few reasons:

You’re introducing new “APIs” for your local application that are not native. This in itself isn’t bad, but it does add to the cognitive load for other developers, so you should make sure there is a value add.

You’re not really going to avoid having to call this._super() because if you had a second component that inherited from “app/components/shared/component.js” then inside of that postInit you’d have to call this._super().

There are actually other lifecycle hooks for a component that may be better depending on your use case.

Also, a few other notes.

When calling this._super() you should always use the spread operator like so: this._super(...arguments);. That will ensure all args are pass to the base class. Even in cases where the function doesn’t have defined arguments (like init), it’s a good future proofing practice.

There is an Ember.on event for init. We use it a lot in our app, but disclaimer there have been some rumblings about it and some talk of deprecating it. You can use this several times. You would use that like so:

You’re not really going to avoid having to call this._super() because if you had a second component that inherited from “app/components/shared/component.js” then inside of that postInit you’d have to call this._super().

If each component extended MyComponent or whatever the name could be,
postInit would always be called. But if there was a component that extended
FooComponent I’d have to call _super() anyway.

This could be solved either by moving some behaviour to a mixin, or, moving
the postInit to re-openedObject class, (or just Component one).

You’re right, whatever solution I’d take, this would add another level of
complexity for other developers.