One level of getParent() is useful to avoid having {{#invoke:}} used directly while keeping the wrapper template simple by not having it have to manually pass through every parameter. Additional levels seem more likely to be confusing and fragile as the template containing the invoke starts to depends on the context where it is called.

In T196501#4258900, @putnik wrote:

For example, you want to prevent the use of the Infobox template directly in articles. But the module can not get this information.

That doesn't seem like something that is all that useful to enforce via a module, rather than by community convention in the same way we typically avoid putting {{#if:}} directly in articles.

A typical cascade of template calls before the module is called is 3-4, and these templates can contain parameters that the module needs to know, or which it is desirable to proxy into the module.

And if the module starts to depend on those 3-4 levels of parents for parameters, it makes the whole stack dependent on those 3-4 levels existing and maintaining the same parameter names.

In T196501#4261621, @Anomie wrote:

One level of getParent() is useful to avoid having {{#invoke:}} used directly while keeping the wrapper template simple by not having it have to manually pass through every parameter. Additional levels seem more likely to be confusing and fragile as the template containing the invoke starts to depends on the context where it is called.

It seems to me that you are trying to prove to me that if allowed to eat with knives, someone will cut themselves. There are several needs that could be solved through a recursive call of the parent frame, and which could otherwise be solved only by cascading parameters forwarding (and no one will solve them that way, over the past two years the tasks have remained unresolved). If this is not convenient for your tasks, and one level is enough for you, you can not use it. But this does not negate the fact that there is a need for such functionality, and there are tasks that it solves.

There is such an example I met today: navboxes has parameter "name" that should be equal to the page title, but one can not add a tracking category because it would include all templates that transclude navboxes in their documentation and there is no way to distinguish them now. If you'd implement recursive getParent, it would be simply frame:getParent():getParent():getTitle() = frame.args[name].

The hewiki site should use secondary parent in 97.2% articles. Without this feature, we are forced to write very ugly and non-exeptable code in hundreds of templates.