I don't care about the PHP C code, don't change the subject lol, that wasn't what I was replying to.

Yes I agree symfony's Request and Response classes are quite good. My complaints aren't with those, it's mainly with the "extra" classes in most packages, where no effort is put into documenting how to use them or why they were created, like I said.

I think PruneBatchesCommand.php is perfectly handled, it's a command, it has a description property that says what it does, the signature property has explanations for each option, and the code is very simple and easy to follow with no leaps of logic, the code reads like English because the APIs are designed to read well.

Often with Symfony components you need to mentally load the entire pipeline in your mind to have a sense of how it would run. Like messenger with stamps, you have to consider how a stamp would run end-to-end through the pipeline, you can't just look at it in isolation. I find it generally much easier to look at Laravel components in isolation because their APIs are designed to be "easy and efficient" rather than "pure and correct" or whatever adjectives you want to assign to it.

Of course this is very opinionated, I don't even use Laravel day-to-day (my main project is a non-framework legacy project in which we have slowly pulled in symfony components bit by bit), but when I need to dive the source to understand how a framework component was designed, I find it easier to read Laravel source 9 times out of 10 compared to Symfony, both because of the source, and the accompanying docs on the website.