The ORM question is a very good example for the issue you describe. Laravel is great to get a CRUD app started right now, iterate very quickly, and leave implementation complexity to the framework. This isn’t the right tool for every job, but it shines at those where it is. For example, you can drop an engineer with Laravel experience in pretty much any Laravel codebase, since the conventions are so strong, they’ll probably understand your business logic upfront.

Additionally, Laravel ships with a huge swath of functionality out of the box. While you’re still researching the best SQL library for a project, a Laravel developer has spun up the framework with a working Postgres connection and starts being productive. There is no value in inspecting the SQL underneath, because the queries never get complex enough to warrant that. And if they do, you drop out of the ORM and write SQL.

As I said before: this isn’t the best way to do something, but a very peculiar way that works well for a specific kind of application. Go is simply a tool for other kinds of applications, where Laravel cannot compete.