I think the title here has gotten me a little confused, but that may be my old school ways of looking at this.
When I see anyone mention a clustered SQL Server, that to me is a failover cluster instance, as AOAG's are technically not clustered SQL servers, they are a collection of individual instances working together, while still sharing the underlying WSFC technology, SQL in an AOAG isn't clustered.
Additionally you mention shared storage, again AOAG's don't use shared storage, that is an FCI which does.
Now you could mix an FCI with an AOAG so combining the two technologies is perfectly acceptable.
Also no downtime, there is always downtime it is just mitigated to perhaps a few seconds and what may be classified as a momentary blip, as the connections would need to be re-established after the failover happens, so unless the application in use has connection retry logic, the applications will error with no open connection and the app will need to be restarted to re-establish connectivity.
So it seems your mixing the two technologies in the post.
I think it would be good to differentiate the two in the article as both FCI and AOAG all fall under the same marketing term of "Always On" Always On Failover Cluster Instances / Always On Availability Groups, and that is all AO is a marketing term.
Additionally, instead of the T-SQL code you posted to find the primary replica, you could also use the functions that MSFT provide you (sys.fn_hadr_is_primary_replica), I have seen issues with stack dumps being generated in the past when querying the DMVs here and the response from MSFT was to use the function. May not happen for everyone but probably one to note that if things do occur.
Overall this is a great post and informative, for me personally reading this, I think it could do with a few tweaks to fully document the topic in question here.