In most cases, it is a matter of taste and tradeoffs that vary based upon circumstance.
You can keep saying "this is the correct way" with all the conviction in the world, but it won't turn matters of opinion and circumstance into universal fact.
Separating the data access layer, the models and the business logic (basically a 3-tier architecture) is a widely used and proven industry standard to keep a sane, maintainable and testable codebase.
Active record ORMs like Eloquent mixes everything in a single layer (business logic in the model events, data accesses are done by the models), but as soon as you reach a significant level of complexity, it is unmaintainable.
Even Laravel codebases that grow in complexity often ends-up wrapping Eloquent in a repository layer.
>Consider Django. There, you explicitly define properties, but link them to the type of database column they'll use. Then, you can generate a migration based upon the model, and then run that migration. I really like that pattern. Removes tedium of writing migrations, preserves ability to modify the migrations, and makes things explicit.
This is exactly what Symfony with Doctrine does, and it's the correct way to do it. The benefits vastly outweigh the "drawback" of having to write slightly more code.