I think this is related to the URL (it only happens with amp pages) more than than the swipe gesture/NTP. Can you check if opening them in a new tab, then navigating using the stack view gives the same result? It does for me.
Probably more related to toolbar, adding Kurt to see if it is related to fullscreen.

The bug is probably somewhere in Fullscreen code.

Hi,
This is listed as a P1 for M62. Are there any updates for this?
Thanks,

Yeah this looks like a fullscreen issue.  I'll take a look at it today or tomorrow.

This issue is still reproduced as of M66.0.3351.0 canary
Tested on iPhone7 plus, 10.3.3 iPhoneX iOS11.3.

crrev.com/c/933921

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e2ec670f6f93cf2994334587b4ab03aa0a9bdca6

commit e2ec670f6f93cf2994334587b4ab03aa0a9bdca6
Author: Kurt Horimoto <kkhorimoto@chromium.org>
Date: Fri Feb 23 22:33:55 2018

[iOS] Move content below header the first time a WebState is activated.

This CL also renames UpdateFullscreenWebViewProxyForReplacedScrollView()
to MoveContentBelowHeader(), as it is used in additional places other
than just for replaced scroll views.

Bug:  769379 
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I330e20e33501429140a8ea3dfd9e8afa34d47fcf
Reviewed-on: https://chromium-review.googlesource.com/933921
Commit-Queue: Kurt Horimoto <kkhorimoto@chromium.org>
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#538925}
[modify] https://crrev.com/e2ec670f6f93cf2994334587b4ab03aa0a9bdca6/ios/chrome/browser/ui/fullscreen/BUILD.gn
[add] https://crrev.com/e2ec670f6f93cf2994334587b4ab03aa0a9bdca6/ios/chrome/browser/ui/fullscreen/fullscreen_content_adjustment_util.h
[rename] https://crrev.com/e2ec670f6f93cf2994334587b4ab03aa0a9bdca6/ios/chrome/browser/ui/fullscreen/fullscreen_content_adjustment_util.mm
[modify] https://crrev.com/e2ec670f6f93cf2994334587b4ab03aa0a9bdca6/ios/chrome/browser/ui/fullscreen/fullscreen_web_state_list_observer.h
[modify] https://crrev.com/e2ec670f6f93cf2994334587b4ab03aa0a9bdca6/ios/chrome/browser/ui/fullscreen/fullscreen_web_state_list_observer.mm
[modify] https://crrev.com/e2ec670f6f93cf2994334587b4ab03aa0a9bdca6/ios/chrome/browser/ui/fullscreen/fullscreen_web_state_list_observer_unittest.mm
[modify] https://crrev.com/e2ec670f6f93cf2994334587b4ab03aa0a9bdca6/ios/chrome/browser/ui/fullscreen/fullscreen_web_view_proxy_observer.mm
[delete] https://crrev.com/9f37416d6fef266dcaeed0b09d0c79584a3d71ef/ios/chrome/browser/ui/fullscreen/fullscreen_web_view_scroll_view_replacement_util.h

+cmasso for merge decision.  This only reproduces when using the toolbar side swipe gesture to switch tabs, so it might be enough of an edge case that we would not want to merge this to M65.

This bug requires manual review: Less than 7 days to go before AppStore submit on M65
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Is the fix risky?

No, I think this is pretty low risk.  The CL is mostly a function rename.  The new logic just moved page content below the header when a tab is activated for the first time, but the implementation of MoveContentBelowHeader() uses the current fullscreen progress to perform its logic so even if there is a bug and it's called mistakenly, it should never result in a situation where the top of the page's content is out of sync with the toolbar.

Since this is not new in M65, let's ship it with M66 instead. Thanks for the fix Kurt!

Issue verified 
Version: Chrome Canary 66.0.3356.0
Device: iPhone SE 
iOS: 11.2.5

Page content is correctly displayed for content suggestions articles. Not sure how to generate an content suggestions article for kotaku.com, but it works correctly as most visited icon.
https://drive.google.com/open?id=1I5FdSoD-efOTFmvxK2aBj-IEzN7xEGUt