Days after our R12 upgrade our wait event alert showed that "ARCH wait on SENDREQ" was quite high, so further investigation showed 9 different sessions in the wait event within gv$session with all of them having the program set like "oracle@server (ARC0)".
The next day, this is what our wait event alert looked like:
Waits Wait Time
gc buffer busy release 6515.7246
gc buffer busy acquire 6243.267722
ARCH wait on SENDREQ 4103.947898
Backup: MML write backup piece 3537.058172
log file sync 3190.876444
SQL*Net message from dblink 2942.456672
SQL*Net break/reset to client 1443.085918
gc current block busy 1434.390776
FAL archive wait 1 sec for REOPEN minimum 1156.983756
Referencing the official documentation again for the definition of "buffer busy waits" and "log file sync" helped us to pin not only the ARCH activity, but everything else going on the next day, down to the SLA conversion process that was still being running post-deployment. What we were seeing was the archiver and archive logs processing from the amount of redo/undo being created in the system, which was why gc (global cache) was so high in the system and the "FAL archive wait" was being generated.