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.

@Ghuron tried to use this function: https://ru.wikipedia.org/w/index.php?title=Module:Wikidata/category&curid=7997060&diff=116271884&oldid=101748397

I would like to add another use case: On the Wikidata wiki we have Template:Query page, which is currently coded with plain-old templates and the logic is split across 12 subpages of the template, making it very hard to extend. I rewrote the logic in Lua however unfortunately the code I wrote is useless because Scribunto does not let me access the grandparent frame ... frame:getParent():getParent() is always nil.

Why do I need to access that? Well {{Query page}} is intended to be used on standalone pages e.g. you might have a page called MyQuery that only contains {{Query page|query=...|style={{{style|}}} }}. Other pages can then embed MyQuery either as a codeblock with style=full or as just a link to the Wikidata Query Service with style=link. The problem now is that I cannot just introduce new parameters to Template:Query page because I would have to update every single "query page" that uses that template to forward the parameters. If Scribunto let me just traverse the parent frames I could easily introduce new parameters.

I would like to add yet another use case for at least have one more layer of getting a parent. Currently, for Chinese localization on mediawikiwiki, because we don't have an extra layer of getParent, we often need to boilerplately use {{LC zh|lang={{{lang|}}}.