The statement you are reading in the Microsoft article says that you should not (and cannot) put a Distribution database inside an Availability Group.
Why?
Because the distribution database is a System database and Availability Groups will only fail over User databases. Therefore you will require another (4th) server in your situation to act as the (remote/scaled out) Distributor.
Distribution database should not reside on the servers that are part of AlwaysON availability group that the publishing database is (or will become) a member of.
Replication configuration is coupled to the SQL Server instance where the Distributor is configured; therefore the distribution database cannot be mirrored or replicated.
If you want to provide HA for distribution database, then you have to go for SQL Server Failover cluster. Thats the only option.
Your scenario is as below :
So if you loose server C, the only option to get distribution running on server D is to do a RESTORE.. with KEEP_REPLICATION from a good backup. You can use this script to restore your distribution database (with some changes as per your environment). I would go for a clean install of replication !
Make sure you script out your replication topology whenever your do any changes. You should have handy scripts of both drop and create, so in a disaster situation, you have scripts that will help easily create replication.
Also, since you are using always-ON with T-Rep, I would suggest you to enable TF 1448.
Trace flag 1448 enables the replication log reader to move forward even if the asynchronous secondary replicas have not acknowledged the reception of a change. Even with this trace flag enabled,, the log reader always waits for the synchronous secondary replicas. The log reader will not go beyond the min ack of the synchronous secondary replicas. This trace flag applies to the instance of SQL Server, not just to an availability group, an availability database, or a log reader instance. This trace flag takes effect immediately without a restart. It can be activated ahead of time or when an asynchronous secondary replica fails.
Reference : Configure Replication for AlwaysOn Availability Groups
Best Answer
The short answer is Yes.
If you can do it in an AG, and you can do it in SQL Server standard - you should be able to do it in a Basic Availability Group. The only gotcha was the distributor which wasn't able to be on an AG - the Replication couldn't work with the listener right - until the releases described in your links.
So you would basically have three AGs. Each with one DB. The distributor would be in one. The Subscriber in another. The Publisher in another.
You have to have your distributor on a separate SQL Server instance. So this would be mean two instances participating in a Basic Availability Group for the distributor, and then two for the Publisher and, most likely, two for the subscriber. Because of the limitations in the Basic Availability Group.
You could have more than on AG on an instance and have one DB in each and that would be good. but your limit here is 1.) You are doing replication, likely for a reason so your publisher and subscriber would likely be on different instances. 2.) The distributor has to be separate from publisher and subscriber.