Reporting can be surprisingly complicated. You can allow users to run raw SQL queries, or have a reporting interface that is basically is an SQL query builder behind the scenes, and have extremely powerful reporting abilities. The problem is you might have a user create a query that takes 5 minutes to run, and then refresh the page 15 times killing your db server/s. Many places have a separate DB read replica (or multiple replicas) just to allow this type of reporting run by certain users.
For an environment like shopify (which I've never used, so speculating), their reports are much more likely optimized database queries or views, or even created from specially stored statistics data not from querying raw db tables, with caching or pre-generation at some point. This means there's a lot of thought behind every report, and what's possible with the current db/stats schema. Adding a column to a report might mean modifying the db schema.
The final issue is that user interface complexity goes up as reporting flexibility goes up. A super powerful interface that few people take the time to use is worth less than a limited interface that provides value to more people. The task is attempting to satisfy power users and more complex needs, while providing a very useful default functionality out of the box.
