The answer will depend on how the reviewer understood 'checking the health of microservice B's REST endpoint'. If service A needs service B to do its work, service A not working will actually cause cause service A to not work. Fixing it should be the responsibility of whoever maintains service B, but service A clearly is affected and you want to know that.
Now, you may say that it should be service B's responsibility to notice there was a problem. However, the definition of 'service B is working' may be different for service A and for service B. Service B may have many different clients, and each may require a different SLA. A response time of 200 ms may be OK for one service, but too slow for another. Centralizing all this knowledge at team B is not practical (especially since these requirements may change and may even the set of services that depend on service B), so it's easier for the client (service A) to check such metrics. Of course, they must communicate with team B and can't unilaterally require them to fulfill some arbitrary SLA.
Another issue is that due to network latencies etc., parameters measured on the servers's (service B) side, may be different than measured at the client (service A). For example, if there is a problem with the network, monitoring on server side may say that service B is up and running, but it might not be accessible from service A, or the response time may be very high due to network lag. So, you need monitoring of service B both at service B (this is clearly more important) and at service A (to handle some rarer cases).