I have a 2 column layout, the right hand column is a scrollable result lists with a max of 200 item results (basically just a ul with overflow-y: scroll; set)>
I tried out your test page and took a look.
First, with scrolling perf issues I like flipping on a few of the checkboxes in the Rendering pane:
Instantly we can see this div called out as "repaints on scroll". You can then verify that in the experimental Layers panel:
(I right-clicked in the tree and selected "Show internal layers" btw)
Now large "update layer tree" costs are usually caused by LOTS of layers or a few layers that are very large in dimensions. In this case we really have neither. But we do have a scrolling layer that's not getting composited scrolling.
Composited scrolling == fast scrolling == usually the default. But in cases like this we fall back to "main thread scrolling" which is really slow and sucky. On the plus side, crbug.com/381840 is just about to be fixed which should fix this test case automatically. Yay! But we can work around it for now.
You did mention you tried will-change and it didn't have an effect, but trying it myself has worked out great. It belongs on the element that has overflow set, in this case its the .map-search__results selector. Add will-change: transform;. Once added, the "repaints on scroll" rect is gone. And measuring with timeline afterwards and it's MUCH better.
Here's a before/after view:
link to viewer
Good luck!