This happens only when you don't check the status code beforehand, isn't it? That's the expected behavior. You can, but you have to follow a failsafe pattern.

Oh, and you need also to pass false to getHeaders() / getContent() if you want to deal with this.
This ensures that code that's written without special care still remains failsafe, which here means not accepting 3xx indifferently to 2xx.
Let me close as I think this issue has been answered.

This happens only when you don't check the status code beforehand, isn't it? That's the expected behavior. You can, but you have to follow a failsafe pattern.

There is no specific failsafe pattern to follow. An endpoint is contractually bound to the response it returns. When we execute an endpoint, we have to check the status code of the response, regardless of the situation. A request that is expected contractually to answer with a 307 is not safe if it answers with a 200. Why would the HTTP client consider 3xx response as less safe than 2xx ones? It knows nothing about the endpoint contract, it can't make such decision.

What is the reason behind this design decision?

Now, about the problem: when we execute a request to an endpoint that returns 3xx responses, the client throws an exception, regardless of retrieving the headers or the content. We don't even get the chance to retrieve them. Or the status code. That's the point. The client just throws.

So, please, it is neither answered nor solved.

when we execute a request to an endpoint that returns 3xx responses, the client throws an exception, regardless of retrieving the headers or the content

It does so only if you don't check the status code. Show me some reproducer I will tell you how to fix it, that's the best way forward I think.

It does so only if you don't check the status code

I don't understand. We never receive a response since the request execution throws. How could check the response status code is there is no response to begin with?

This is what the documentation says by the way, so the behaviour that we are observing is consistent:

if the number of redirects is higher than the configured value, you'll get a RedirectionException

Why is the client working in such a way? What is the rational behind not supporting 3xx responses at all?

We never receive a response since the request execution throws

Yes you do: just get the result from the call to $client->request() and you'll have the chance.
About the why, I think I already explained why, and the doc also tells about this.
That's an API that's designed to be failsafe. It might surprise you, but that's nonetheless on purpose.

It is not explained in the doc, except if I missed something. And the failsafe argument is fallacious : an endpoint that is expected to return 3xx should not fail when it does actually return a 3xx. The client is not failsafe: it actually induces failure; and it is not failsafe when it should be - typically in this case when the response is a 2xx, it should fail.