Hey Lucas! I agree: your option #1 is the way to go. I think it’s super-important to take the modeling logic that your analyst team builds out in SQL and make it accessible to all of your data consumers throughout the org, and hashes are a big problem.
This is a super-common ask we hear from folks that implement Looker as a part of a larger data stack. For example, folks with analytics and data science teams want to be able to model their data not only for analytics use cases in Looker but also to consume via Python/R/etc. This is one of the major reasons we built data build tool (dbt). dbt is a data modeling layer very similar to Looker PDTs but with several advantages: incremental data models, no hashes, automatic dependency resolution, multi-threaded runs, etc. Instead of building your SQL transformation logic in a PDT, move it to dbt (which is open source and free to use!) and you’ll get all of these benefits out of the box