This is probably the most feasible and easiest option and to implement for the simple case. It will likely have the most impact at the lowest cost.
Some concerns though:
- Infoboxes - It is nigh impossible to determine how to add an image to an infobox consistently using template parameters
- Cultural differences - some images are perfectly fine in one culture but may be offensive or inappropriate in another. This may lead to "editphoto wars".
- Rating - frankly commons has too many images, so using rating or pageviews to surface possible candidates makes sense.
- Duplicate work - the page image could primarily be stored in wikidata to reduce duplicate work in other wikis
- Wiki preferences - It might require adding more properties on wikidata to ensure that each wiki can choose its preferred image there. This may reduce arguments over which image is best for which wiki.
For infoboxes or templates that add images, the ideal option might be to add a new property to templatedata, maybe something like parameter type:
params": {</nowiki> "user": { "label": "This is the main image. It is shown in search results, and represents the page", "type": "main-page-image",
If no infobox exists in the article, it can just fallback to adding the default markup, e.g.: "<nowiki>[[file:page-image.png|thumb]]</nowiki>". Yet another alternative might be to use the image from wikidata whenever this parameter doesn't have any value. This might be highly controversial, and this wikidata functionality could be opt-in for wikis that want it.
The simplest MVP implementation is probably to avoid infoboxes altogether, and just add the "standard" file:image markup to the article only when there is no "infobox class".