Luckily, figuring out what would be a good thumbnail for a page is a "solved problem" in the form of Extension:PageImages.
It's enabled on most wikis, with the exception of wikibooks, wikisource, wikitech & lockeddown (loginwiki, votewiki). Is also (usually) only works with the main namespace.

Findings:

• These are already used in the MW REST API (T250144) & New Vector's fancier search, and are used as the article's Open Graph images
• This is not built-in (into MediaWiki core) behavior. It requires an extension (not present on all wikis), so we're going to need the ability to turn this off completely.
• Usually, only articles in the main namespace have a known thumbnail. We'll need to consider (largely) thumbnail-less searches when users get lots content from other namespaces.
• Even within the main namespace, the majority of articles have no thumbnail. I'm willing to bet that there's a good correlation between <prevalence of articles in search results> and <likeliness to have an image> because both tend to increase with more article content. I expect the best matches to be most likely to have thumbnails. Still, lesser matches (or more obscure searches) will likely yield many thumbnail-less results.

Pinging @Sneha for FYI.

TL;DR: I expect the majority of searches to have pretty decent thumbnail coverage for the better matches. But there are still going to be many cases (far too much to ignore) where we will have little or no results with thumbnails.

I have run some numbers (see below) on the thumbnail availability on a wide random selection of projects/languages/namespaces if you're interested in more details:

enwiki

dewiki

hewiki

ptwiki

ruwiki

plwiki

enwiktionary

dewiktionary

hewiktionary

ptwiktionary

ruwiktionary

plwiktionary

enwikiquote

dewikiquote

hewikiquote

ptwikiquote

ruwikiquote

plwikiquote

enwikinews

dewikinews

hewikinews

ptwikinews

ruwikinews

plwikinews

enwikiversity

dewikiversity

ptwikiversity

ruwikiversity

enwikivoyage

dewikivoyage

+-----------+-------------+------------------+

hewikivoyage

ptwikivoyage

ruwikivoyage

plwikivoyage

commonswiki

wikidatawiki

specieswiki

If anyone is interested in numbers from another wiki, LMK and I can run this query again:

SELECT page_namespace AS namespace, COUNT(page_id) AS 'pages total', COUNT(DISTINCT pp_page) AS 'pages with thumb'
FROM page
LEFT JOIN page_props ON pp_page = page_id AND pp_propname IN ('page_image', 'page_image_free')
GROUP BY page_namespace;

Questions/answers:

Again pinging @Sneha in case any of below is relevant.

2. How can we present the image in the thumbnail?

Mostly a design question. We can probably stretch/fill any way we want, depending on design preferences.

3. Is the thumbnail data already available in search results or do we need to pull it in via the api?

They're in Extension:PageImages. We can access them via API or get them from PageImages::getPageImage(). They live in an extension, though, so we'd probably need to use some Hooks mechanism to allow passing the data around, or make PageImages a hard dependency (which would exclude building this into core)

4. How many articles have images? And are we fine if the majority don't have any?

See previous comment.

5. What do we want to do for non-content namespaces?

Those will usually not have thumbnails. PageImages doesn't even capture them outside the main namespace (we could change that if needed), but most of those pages doesn't even have any imagery anyway (and for those that do, it likely often isn't relevant; e.g. the random imagery on User pages)

6. What is the optimal resolution for likely-warm-in-cache to maximize image delivery?

wgThumbLimits sizes are most likely to be pre-generated, warm in cache. Other sizes could be requested, but it may take some time to generate those images in those sizes (and for something like search that may generate many at once, this may cause too many requests where images fail to be served)
These widths are: 120, 150, 180, 200, 220, 250, 300, 400 (along with 1.5x & 2x responsive versions)
We can always downscale the thumbnail on the client, but upscaling will lose quality.
Basically, anything up to 400px would be fine.

I have explored a few options as shown in the image below. I am leaning more towards option 2 where we align the thumbnail to the top. The height of the thumbnail may vary but the width will always remain the same and you always see the entire image. And option 4 is good too if we are able to do it in a way we don't crop of people's faces but I know it is hard to predict where in the image the face is. Let me know your thoughts.

Also regarding namespace results, I am thinking we should treat them differently with no thumbnails and only have thumbnails for articles (even if there is no image use an empty state thumbnail for articles).
Having namespace results and articles look different is good because I am thinking we should reserve quick view only for articles and so that visual difference will help users understand the behaviour.

@matthiasmullie @Seddon

I think the Go bar autocomplete thumbnails are currently set to option 3 in the image above. But it would not look good in a bigger size if things were cropped inappropriately.

New Vector does #3, a simple centered fill, indeed.
#4 would also be easy to do - we still can't predict what'll fall off, but cropped faces would become a less likely occurrence (though other important stuff might be in the lower parts)

I didn't have to look too hard to find examples of images where the height or width is at least 2x the size of the other measurement. E.g. wide landscape or high portrait.

Filling out a square would lose a lot of detail in these, but having wildly inconsistent thumb dimensions may look awful as well.

Personally, I think I prefer #3 & #4 over #1 & #2 for this specific purpose: losing some cropped details isn't too important IMO (it'd still help you understand what the page is about), but I'm afraid that the visual inconsistency of having a variety of formats & their positioning might be rather distracting (or not, IDK, haven't actually seen it in action, assumptions may be all wrong :p)

Hmm I saw your examples and yeah some of those very wide and very tall examples would not work so well for 1 and 2. if we are able to do #4 easily (which I assumed it was not easy to do since we don't do it elsewhere) then we can go with that. We will have a full image in the quick view so agree a bit of cropping may look better than some very wide/tall images fitted in a box. I am guessing if we show the top of the vertical image most of the time we may be able to avoid cropped faces.

So here is an example of how cropped will look. Note that only first image is showing the top of the image rest are not but if we go with option 4 they all would.

And example of option 1 (2 would look very similar)