> servers cannot periodically advertise their load measures to clients
This is an asynchronous mechanism - you can use polling, push, or queue, or whatever. Individual responses don't pay the cost.
> staple current load reports to query responses, which the client can cache and use for a period of time
This is just a few extra bytes in the response, which likely has negligible cost. One can fairly reasonably say that responses don't pay any cost.
Obviously there are other costs - it just depends on what you're trading off between on whether it is the right decision.
The advantage of P2C is the simplicity that comes from its stateless/just-in-time nature. If you cache load, either by servers broadcasting or including a load indicator in the response, you have to consider cache invalidation and TTLs. The longer the TTL, the higher the odds of a thundering herd (all clients think one server is under loaded and proceed to overload it). If you're undertaking this complexity, it may be better to go with a proxy, which can have other benefits too (connection pooling, no client cooperation required). Like all such decisions, it depends on the situation.
This does depend on having a local load balancing layer (not, say, making a choice between two servers that are each 50+ms away from the load balancer), and also having a high-performance RPC stack (C++ on both sides, and Thrift, in my case).