It's active/standby(old style), it will go from server to active to other server and reply from that server to active back to other server. Depending on the hashing on the server it could go two ways, either direct from server to active, and then to other server. Or, if the server hashing sends it to standby it will go to standby then standby will send it to active over peer link and then active will send it to server.
In newer VPC code (like even 6.x i believe) this should automatically be active/active with HSRP now, and it should use the VMAC and the VMAC will be installed on both switches, however not all devices use the VMAC properly and thus this feature:
peer-gateway feature, the standby installs the active mac address in its own table with a "G" (gateway mac) and then if the server hash sends it to standby, it will do lookup in routing table and send it to other server instead of sending to active first. So both will be used in routing path all the time, like they should be.
Even more clarification: active/active doesn't mean both hsrp groups are active, it means both switches are active forwarding ipv4/6 for the SVI. HSRP will still have an active/standby. How this works is that the switch inserts the HSRP VMAC into the mac address table, which you can see with a G next to it. This exists on both switches in the pair, where without VPC would be a duplicate mac address.
So the peer-gateway is only necessary if the devices don't put the right mac address in their table.
Peer-gateway could also break some routing protocols and that's where the layer3 peer-router tweak comes into play.
I would not use it unless necessary, as always test you configuration first.
Let me clarify a bit:
Peer-gateway was conceived to fix issues with certain platforms that don't set their arp entries to the virtual mac address properly ( some load balancers and storage gateways and such)
HSRP is supposed to have a virtual mac address created and the servers use that as the destination but some platforms don't do it. If they use the vmac properly, then peer-gateway isn't needed.
If you look at show mac-address table without peer-gateway, the mac-address for the primary will show as being on the peer link. Thus any layer2 frames destined to that mac address hitting the other switch will go over the peer link to it like normal layer2 should work.
The peer gateway enabled, you will see this mac address in show mac-address table with a G next to it. This means any frames destined to this mac address will now be processed by this switch. In basic terms it adds the mac address of the vpc peer to the switch as a destination to process incoming frames. This means it will now take ipv4 frames in and process it as if the destination was this switch and not the peer switch and that is what makes hsrp active/active.
This is one of those things that sometimes is needed sometimes is not.
My previous reply was based on the device not using the virtual mac so I will edit it to clarify. Some devices have problems with it because the arp reply comes from the switch system mac and not the vmac but the vmac is the mac inside the arp reply. I think they should fix it so it comes from the vmac and then peer-gateway is not necessary at that point.
VPC will only drop frames over the peer link that would be in the same bridge as a VPC enabled port (and that port is active) on the other switch. If it's an orphan port it will still forward frames. Technically the peer switch is not in a vpc group and when you ping the switches from each other they will go over peer link.