We currently delay 2.5 seconds before writing to the sessions file. So, if you scrolled and then crashed within 2.5 we would not have written it to disk.

Ah, that probably explains some of the inconsistency I was seeing with crashing individual tabs. I just tested again with the following:
1. Go to https://www.nytimes.com/2017/07/28/us/politics/reince-priebus-white-house-trump.html?hp&action=click&pgtype=Homepage&clickSource=story-heading&module=span-ab-top-region&region=top-news&WT.nav=top-news
2. Scroll partway down the page.
3. Wait 10 seconds.
4. Go to chrome://inducebrowsercrashforrealz
5. When the browser restarts, restore tabs.

And the nytimes page was scrolled to the top.

Oh...hm...maybe this is something to do with nytimes.com. If I do the same steps with https://en.wikipedia.org/wiki/Main_Page we do restore the scroll position.

But if I gracefully reload the nytimes page (with or without clearing cache), it seems to reliably restore scroll position. So, there may still be a session restore bug here. I'm not sure.