Why am I seeing poor performance on SQL server 2019 and asynchronous AlwaysOn
You have the AG set to async mode, which means the difference isn't due to HADR_SYNC_COMMIT waits.
Just the overhead of compressing and sending the log records to the secondary replica(s) could explain the small differences you've noticed though.  Especially if the workload is so sensitive that a 2ms difference per query results in noticeable changes.
Per the really useful Thread Usage By Availability Groups docs section, your primary server will use

1 Log Capture thread for each primary database. In addition, it uses 1 Log Send thread for each secondary database

In the background during your normal user query workload, these threads are reading log records as they are committed, compressing them, and then sending them to each of the secondary replicas configured.
These threads will use CPU time. If the workload is write-heavy (lots of inserts and updates), it could be a noticeable amount of CPU usage.  If there are multiple AGs, multiple databases in the AG, or multiple secondary replicas that need to be updated, even more CPU usage will be needed.
IF the increase in query runtimes is due to AG thread CPU usage*, one possible solution would be to enable trace flag 1462, described in Tune compression for availability group:

Disables log stream compression for Availability Groups with asynchronous replicas. This feature is enabled by default on asynchronous replicas to optimize network bandwidth.

You'll end up using more network bandwidth, but the primary server won't spend CPU cycles compressing log blocks before sending them to the secondary.
*You could try confirm this is the case, potentially by checking to see if queries are experiencing signal waits at a higher rate than on your previous server.

Note that this answer focuses on the availability group aspect, since that's a major difference between the systems per your question description.
The difference in performance could be numerous things, including even minor config differences that can make a big difference.  Considering using the free, open-srouce sp_Blitz procedure to check for anomalous settings, offline schedulers, etc.