Interesting and well written, but I disagree with your slant.

Much of this article is based on assumption that your DR instance is providing HA. In my experience, with a moderately busy environment this is not possible...you will not be able to tolerate a synchronous AG secondary across WAN. In such an environment, your 2-node async AG-only solution then has DR but no HA.

In such an environment, you can readily achieve HA with either an FCI solution or by adding another local synchronous AG replica. The complexity is about the same either way.

Yes FCI requires shared storage. This may represent higher cost for some shops, or may represent disk savings in others. My company is in the latter camp.

The drive letter problem is pretty simple to work around without removing nodes from the cluster. One way is to simply configure the shared disk drive letters in advance of installing the SQL FCI. Not a big deal.

Finally with regard to FCI's lack of automatic failover to DR: you can only have automatic AG failover to DR if your DR replica is synchronous. This is not tolerable for my production setup, and I imagine that is fairly typical? I believe that a common scenario is for the DR replica to be asynchronous, with no automatic failover. If a disaster takes out both your primary and HA nodes, there will be an outage until you manually move bring up your DR AG (and deal with any cluster/quorum issues)...this applies equally whether you're using FCI for HA or using a synchronous AG for HA.

Two scenarios that we currently support on our production servers include: a) an FCI for HA and an async AG for DR; and b) a sync AG for HA and an async AG for DR. For a number of reasons beyond scope of your article, I am coming to prefer the former more and more over time.