HTTP/2 server push is odd. When you can get the most benefit out of it, you usually don't care, because your resources are small and load quickly anyway. And when you care (because your resources are big don't load quickly enough), HTTP push actually hurts you, because you are pushing the same big resource on every page load.
I have tried to use it once, and the hassle of distinguishing between first time visits and repeated visits is simply not worth it. Even the hassle of using <link rel="preload"> is usually not worth it in large apps — if you have time for that, it can be better spent on reducing size of assets.
I think the benefits are where some automated system writes your "preload" entries for you.
For example, a webpack stage could render inside a sandbox each page of your site, detect which resources get loaded, and add all of those as preload/server push entries. The server itself can keep records of which resources have been pushed to a specific client, and not push them again.
Writing preload lists by hand is never going to scale with today's web apps with hundreds or thousands of requests for a typical page.
I have tried to use it once, and the hassle of distinguishing between first time visits and repeated visits is simply not worth it. Even the hassle of using <link rel="preload"> is usually not worth it in large apps — if you have time for that, it can be better spent on reducing size of assets.