Suppose you set up AlwaysOn but something goes wrong with your partition switching process and you accidentally delete all of the data. With your current proposal you'll automatically delete all of the data from your archive database as well. So even with AlwaysOn you'll still need to take backups, right?
Now consider the state of your current database immediately after you perform the partition switching. That's what you want on the archive database, right? So if you still need to perform backups anyway why not skip AlwaysOn and just back up and restore that database immediately after the switching?
You might have other reasons for using AlwaysOn so I can cover a few pointers but I'm not really an expert. At a high level, SQL Server keeps the databases in sync by replaying the transaction log so the secondary database is a byte-for byte-copy. A decent approximation of how an operation will affect redo traffic can be found by looking at how much data is logged to the transaction log. Partition switching doesn't require data to be moved so very little information should be logged. This means that you should not expect it to cause issues with AlwaysOn traffic.
One problem that you might run into is that you can't pick and choose which tables or filegroups get synced. It must be the entire database. So you'll be sending the transaction log activity for the "large amount of inserts per day" and anything else that you do through redo to the secondary. Your active database will also continue to grow in size over time switch you can't partition switch across databases as Sean Gallardy pointed out. So right now if your active database is 100 GB and your archive database is 1 TB you'll need to move all of that data from the archive database to the active database if you want to put them in an availability group.