Looker's visuals seem to be designed almost as if Google had a drag and drop product for your central reporting needs. The visuals are clean, and it is very easy to plop a number of visual representations on top of a query.
Looker forces a company into two streams of thought: an analyst first culture and essentially married to Looker. Looker really thrives at young or small companies with no centralized reporting or analytics/data science teams. For the few people who know SQL, they can create these items called Dimensions and Measures which are essentially saved queries for qualitative and quantitative data. Instead of having someone write a query with many caveats in a where clause or in cast type conversions, these Dimensions and Measures are meant to save you the trouble of writing them and be ready to drag and drop into an editor for a quick dashboard.
Unfortunately, this only useful for companies just getting out the gates with their data. If you have a column such as customerId, you cannot write SQL in looker to get an aggregate count of customer id's. You need to create a new dimension for it, and have it uploaded. If you have a count of customerIds restricted by some WHERE clause, then you will need to upload that new value as well. All the new measures and dimensions that you need have to be uploaded, which means that you will be responsible for learning Looker's LookML to upload new datapoints.
As a company gets larger and as more departments are formed, your Looker repository will suffer from a lack of grooming. There will be a ton of dimensions and measures all over the place in different schemas and with different underlying queries that no one person will be able to explain. There will also be a massive amount of unused charts and visuals that were created ad-hoc and are relatively unused because they were spur-of-the-moment replacements for an Excel sheet.
This also means that much of your business logic and data governance resides within the tool. If you were to divorce yourself from Looker, it would be a very messy process. Troubleshooting queries is already a challenge because you must look at the underlying code for a dimension or measure. Real trouble starts when Looker creates its own material views, which creates another layer of abstraction that you must then troubleshoot.
This process of ad-hoc adding usable dimensions and measures in a tool through LookML and then troubleshooting the queries underneath the hood is not scaleable and no company with a centralized analytics function should allow it to happen.
Invest in a tool which can intake an actual query through a database connection, and keep those queries thoroughly managed and groomed in a version control system. Create a dashboard environment in which a core group of people build an ecosystem of dashboards for specific requests and educate people on how to read and interpret them.
Do not get into the business of enabling everyone in your company to have the ability to create their own ad-hoc visuals and set of dimensions and measures; you will truly regret the chaos that comes with it.
Consider if you want a playground for people to create whatever dimensions, measures, and views that they want, or if you choose to proceed with more governance in your BI decision.
Also note that you will have to learn LookML, which isn't difficult, but it's also like why? You are paying to have to learn a company's proprietary wrapper on SQL on top of hiring people proficient in SQL.
If you do purchase Looker, I would highly consider centralizing the function of people who will create visuals and make things to address specific requests, and limit the views that Looker creates.