There's a lot to unpack here. I agree that there are few true experts given the amount of time and effort required to develop genuine expertise. Also, that often requires a very specific focus even within the larger SQL Server ecosystem that is not an option for many people given their responsibilities. Someone who is solely a DBA will be in a much better position to develop a deeper understanding of that domain than someone tasked with DBA, reporting, and application support. I've met plenty of people who stagnated largely due to their own complacency, but that's not always the case. People get pushed into roles that they don't want and know they're not qualified for, denied licenses training and tools, etc. for a myriad of reasons outside their control.
What I really find troubling is how often technical people fetishize and covet "expertise" for its own sake. At root, I view any technology as a tool. Expertise with the tools is only valuable if the end result and goal adds value.
Take for instance the example given earlier in this thread where someone indicated that they could drastically reduce a 2 hour run time for a query. I agree that all other things equal, shorter run-times are preferrable. However, one should ask whether the current duration is a problem from a business perspective or not, and balance any gain from a performance improvement against time invested in refactoring, testing, and future maintenance.
Same with investing time with keeping up with any new bleeding-edge features or releases. Before spending time learning about it, assess the rationale in terms of a value proposition. I want to learn about "X" because I believe it will enable me to do "Y", which yields the following tangible benefits.
Being able to understand, quantify, and articulate the business value of what you are doing or want to do helps focus your efforts on activities more likely to yield a tangible return and helps you influence others to get on board.