Shipping big WAL archives to hot standby
First, in case there's an implicit misconception here: Note that the restore is not atomic. Your queries on the replica will see the intermediate states between the prior and new master state. It'll happen faster than it did on the master - assuming the replica replays reasonably fast - but clients will still see it and there's no way around that.

If you're trying to give clients an apparently atomic switch between old and new states you can't do it just by copying a bunch of WAL over.




  What would be the effect of suddenly introducing a 1-2 GB of WAL archives to the WAL restore folder on the slave? 


Minimal. The only significant effect will be the disk I/O of writing it as you copy it.


  Would there be a big performance effect on the incoming queries to the slave?


Mild to moderate, probably mild. It'll have more impact than streaming them continuously would since the replica will be running restore flat-out so it'll churn the disk, kernel buffer cache and shared_buffers more.

Hard to say in detail, depends on workload, RAM, disk subsystem, etc.


  Would the slave be available for queries while the WAL logs are restored into the DB?


Yes.



Another alternative you may not have considered. It still needs 2x the disk, but:


Run pgbouncer in front of the replica.
pg_basebackup the replica locally to a temporary datadir. Yes, you can take a pg_basebackup from a replica.
Copy the WAL to the copied replica.
Start it, wait for it to catch up.
When it's caught up, change pgbouncer's configuration to point to the  new DB and sighup it to get it to reload its configuration.
Shut down the old replica


... and repeat, switching between the two datadirs.