What are "wiki-specific" templates? Are they the things that will cease to exist once we have global templates (T6547: Support crosswiki template inclusion (transclusion => interwiki templates, etc.))?

No. We're writing software for all MediaWiki installations, including those in air-gapped bunkers without access to MediaWiki.org's shared templates (or whatever). :-)

Even with the list of "blocked by" tasks here, it's still difficult to discern exactly what type of templates we're discussing here. Which templates don't scale? Which templates don't work well for many situations?

Broadly, I thought we were trying to either keep wikitext as complex as it is currently or reduce its complexity. Extending wikitext further (e.g., by making <gallery> syntax more complicated) stands in contrast with this perhaps outdated principle of keeping wikitext from growing.

I also see this task as intersecting with the need to clearly define how VisualEditor will handle wrapper wiki templates (if at all) and how Parsoid will handle wrapper wiki templates, particularly partials. In general, I agree that templates on individual wikis have been used as a crutch or a hack to work around limited "built-in" functionality (i.e., functionality from MediaWiki core or one of its extensions), but I very much doubt we'll be able to eliminate the long tail of wrapper templates, so figuring out a more robust approach seems prudent. Maybe this has already been done elsewhere.

This approach is hopeless and counterproductive. The whole point of templates is that the community constantly revises them and constantly creates new ones for new functionality. The moment you expand and complexify core wikitext to make some templates "unneeded", the community will just start making new templates incorporating that wikitext.

The only result is futile redundancy and complexification added to core wikitext.

T176242: [EPIC] Representing / extracting wiki-specific application-level semantics seems relevant to this task.

One other reason some users prefer to use template is that its name can be localized. E.g.: {{Referências}} (in Portuguese) instead of <references /> (in English)

If you want no-one wants (or needs) these templates let's examine what that means. There is discussion of putting the new #shortdesc keyword in a template. Here's a list of functionality currently planned, or under consideration:

• Displaying a custom text.
  • Conditional display: That text should only display in preview mode.
  • Conditional display: Is a value supplied?
  • Conditional display: Does the value match any of a list of community-defined special values?
  • Conditional display: Alternate text, if the value is longer than # characters.
• Including the page into one or more categories.
  • Selection of category/categories may be dependent on whether a value is supplied.
  • Selection of category/categories may be dependent on whether the value matches any of a list of community-defined special values.
  • Selection of category/categories may be dependent on the length of the supplied value.
• On-the-fly translation of values. An absent value , or selected special values, may be converted to different specified values before passing those values to the #magicword.

This task is fundamentally is misguided and doomed. Even if you obviate the need for a wiki-specific template, you must expect that it's just going to be re-wrapped in a new template at any time.

The core wikitext functionality should only be changed when it truly makes sense to incorporate specific functionality into core even if it gets wrapped in a new template 24 hours later.

One point that is not considered here is that core features are good in some ways, but completely and utterly terrible in many other ways. If you don’t have original developer of some template, maybe some other pal can fix it. If you don’t have original developer of an extension or a core feature, you’re completely lost until some other developer can grace you with their presence to upload a relevant patch on Gerrit or something.

3 quick examples from my practice:

1. T177596. We in Russian Wikipedia have removed all our language userboxes in favour of Babel-based userboxes. Babel has many positive sides in localisation etc., but the downside is that 1) probably no one tested Babel for production and therefore basic features of Wikimedia templating have been forgotten, 2) Babel is apparently not being developed now, so no one acts on the simplest request to add nocat= to a babel box for 6 months already.
2. T164445. I wanted to redo Edittools box in Russian Wikipedia to have a more semantic layout and was confronted with a technical problem with using line breaks in it. Charinsert extension, on which Edittools are dependent in the projects, is also apparently being neglected by developers, and my request will soon mark a year to be fixed.
3. T164532. Also wanted to use a core feature of a slideshow box (although I did some tweaks to it) and was confronted with a technical problem. The task is also soon will mark a year.

And so on, and so on. The idea to ‘obviate the need for templates is a pretty one, but it is completely unrealistic. It increases entry point for non-PHP developers, it puts a clear hierarchy between the communities and the developers in the future (since WMF/WMF-adjacent folks always get their word last, there is really no way to override their decision in times when even a larger community than entire tech-related team here has already decided to do it).

I expect the stuff like Capiunto (an extension for rendering infoboxes via Scribunto base module) to go exactly this way − as an another way for active Wikimedia developers to impose their will over the will of communities that have been doing fine without that in exchange for some features that might be cool.

A constructive proposal in all of this? Don’t aim to ‘obviate the need of templates’, since it is unrealistic and regressive goal that harms any potential progress in local communities. Aim to provide a basic blueprint for Wikimedia communities in terms of gadgets, modules and templates that provide the basic agreed-on functionality that is essential for building a great project. If something can be realised without an another catch-all extension, then it should be. Since, ultimately, core features don’t have a track record for being supported years into making. Gadgets, modules and templates do.