drive-by:

I think this always happens on the first character of input; it has nothing to do with rich entities.  The omnibox caches suggestions for use on later keystrokes, so the asynchronous updates (when we receive updates from the server) are little dramatic then.  You can see this in on current stable.  Revising summary.

On the first keystroke, if we want to show server-provided search suggestions, we need rows to "pop in" late.

I'm inclined to WontFix, unless UX thinks this is especially problematic nowadays with rich entities?  It hasn't been a concern to UI/UX for years previously.

Agreed that this is probably WontFix just because I don't know how we could fix it since we don't know in advance whether or how many server responses we'll get.

That said, the entities are so visually dramatic that they do exacerbate the "pop in" effect so I think it's worth giving this some more thought. Like maybe a fade-in animation as ellyjones suggests.

GSA has significantly better scoring for those suggestions than we do - and they tend closer towards the bottom, which is less disturbing. 

We might want to reach out to them if they have some scoring suggestions to share. 

I'm leery of animating them in, because animations are likely to grab *more* attention than popping in. Can we first address the flicker to see if that ameliorates the pop-in effect?