I think that people believe they'll switch out components more than they really end up doing, but in Laravel, you can override things within Service Providers, and then use the built-in dependency injection to get the thing you want.

Laravel is great for prototyping and fast building. If you want to make a big application with Laravel, it's better to use Symfony-like approach with interfaces and DI (you can do it by using Laravel). What I personally do not like in Laravel is their ORM, too much magic calls involved.

Yes, the magic involved in Eloquent ORM, also the central use of Facades or that the models are based on migrations (which uses code comments as a crutch for auto-completion), instead of the migrations being based on the models (how Symfony uses simple PHP objects, from which then Doctrine generates the "missing" migrations).

I can live with both frameworks, but Symfony just feels cleaner and more transparent in its workings without using magic to make things look simpler.

This is the big reason I use Symfony for most of my projects.

I do lots of refactoring and modernizing of legacy or non-scalable codebases as a freelancer; with Symfony you can replace it module by module and slowly implement the Symfony framework structure.

Through some configs, it can do dependency injection, event listener stuff, etc, but the framework is mostly glue around components.

With Laravel, you need to go "all-in", and you had to do things the Laravel way. If I strayed from that path, it would make things really difficult.

I still work on projects with either of the frameworks, but if I had a choice, it would almost always be Symfony.