Is SARGable query the first thing to put in developers' minds? Is SARGable query the first thing to put in developers' minds from a performance tuning perspective?
It's been a while that I work through this way, but I was just wondering if you guys have the same approach, considering Microsoft will not Make more functions SARGable.
This is a bit tough to answer with the lack of details so I will share my experience. I help teach a short class to new developers about SQL optimization at the company that I work for. We do OLAP on SQL Server.

The concept of SARGable arguments is important and definitely mentioned in the class. It can be used to avoid basic mistakes, but it won't be much help for developers if their query is performing badly and they aren't making any of those mistakes. We try to focus on the fundamentals of queries and to teach developers how to interpret query plans. In my opinion, the three most important things to understand well are table access methods, join types, and join order. If developers understand those three things well then they'll be in a good spot to troubleshoot most performance issues, at least with our workload.

By table access methods, I mean how to identify if a table is being accessed through an index or not, when to expect index use, and the consequences of not using an index when you should. Same ideas for scans versus seeks. By join types, I mean the usual nested loop, merge, and hash varieties. When to expect each and what the consequences are when SQL Server gets it wrong from our perspective. By join order, I mean the order of tables in the query plan. If there is a table that greatly restricts the number of rows returned by the query is it processed relatively early in the plan? If not, why not?

If developers have a decent grasp on the basics then they should be well armed to identify lots of different performance issues, including those covered by the SARGable concept.