We are pretty new and picked the virtual appliance. Just because it's bundled with lots of stuff doesn't make it just easy peasy plug and play unfortunately; specific gains may depend on your environment.
While it does come with things like the database built-in, it also has limitations OOB which are not documented how to architect around.
Some considerations below on the virtual appliance that we've run into.
These are not meant to scare you away from it ...just to be aware of them in case you've already got a good infrastructure for supporting OS deployments and a supported DB setup. We did not have a supported DB in place which was a part of why we chose virtual appliance in order to get that all bundled together in one package.
My real preference would be both the API Gateway and the OTK to support our database and use the software gateway. However, since the base product supports XYZ DB's but OTK supports ABC...we weren't left with much choice short of building out a new DB infrastructure; just keep that in mind with DB support because CA is inconsistent across their products - and with API GW even within the product - except maybe Oracle DB (that seems to be across many that we use).
--- Patching and upgrades ---
If you have a group that already manages your OS and app patching via automated tools it may not translate over to them. For example, our team now has to handle monthly patching instead of our hosting group, which is an extra ops activity for our admins that will eat up their time from working other enhancements.
The few patches we installed were not a big problem for CRs under 9.2. Up until 9.2 -> 9.3 which dorked up the MySQL stuff; caused quite a few replication errors and problems that we're having to spend a lot of time with CA support on.
--- Built-in MySQL replication limited to 2x ---
No "official supported setup" for multiple data centers replicating across the MySQL (i.e., more than 2x databases); instead of documenting how to set this up, you might be asked to spend $$$ for professional services instead. It is supposed to work but undocumented and no information provided on how to set it up in a supported way; this is wrong IMO and CA should provide at least general guidelines/instructions on how to configure this setup.
It also defaulted, and was undocumented, in 9.2 to be unencrypted clear text. Not sure about the default for 9.3, but you'd want to check that because it was insecure by default sending updates and queries in the clear across the wire. There's steps to setup TLS but requires manually configuring it all.
--- No strong authentication to the console ---
The appliance supports local username+password default. It says it can be configured for LDAPS to AD for password log in using something like a CA PAM managed account (short-lived password checked out via Smartcard)...however, their AD LDAPS setup is not implemented very well and YMMV on getting it working; we worked with CA Support for quite a while on this and it never did work so we gave up and used CA PAM and monitoring to manage local accounts on the appliance itself instead.
Additionally, even if/when you get that setup there's always required to be a fallback log in account. So the risk of a local password always exists that has to be mitigated via managing the account and monitoring.