Thrift and gRPC can "push" until the cows come home (streaming). Use the correct tool for the job. HTTP is for hypertext documents, not APIs or RPC.
Note that gRPC never used HTTP/2 PUSH_PROMISE frames so it isn't affected by their removal. gRPC's bi-directional streams have to be initiated by the client.
RPC is another API style, but it's more tightly coupled. RPC has been tried and tried and tried and the same problems happen all the time. Tightly coupled, brittle, hard to upgrade.
If by "gRPC" you meant protobuf as a message format, then sure. But TLV based binary streaming has been around for yonks (eg ASN.1).
Pushing is an optimization to avoid API round trips, not just the capability of sending a binary stream.
Link headers have the same effect as HTTP/2 push, but a client can cache previous requests (and the new 103 Early Hints status).
It's a hint from the server that it's highly likely that the Link URLs will have useful information in terms of the current request.
It can be seen by caching layers between the client and the server, so they can pre-cache the links or deliver them without server interaction if previously cached.
All of that is part of HTTP, which has nothing to do with "hypertext documents". It just happened to be that hypertext documents were the first use of the protocol.
REST is good for things like downloading and uploading documents or media to a web server. GET, PUT, POST, DELETE, etc. were designed for documents/media. Because it's available from a web browser, like JavaScript, people started using it even on native apps because it's familiar. That doesn't mean it's the best or most productive protocol.