I won't express an opinion on the backup strategy but...

>>any database backup maintenance plans on the SQL Server server.

What about a maintenance plan that cleans up the SLQ log file and resets it?

The SQL Transaction Log pruning/truncate process would depend on the Recovery Model. If it is Simple Recovery Model on the database(s) then SQL Server does this process automatically. If it is Full Recovery Model then you will want to need to perform SQL full backups and SQL transaction log backups. You can read more about this The Transaction Log (SQL Server) - SQL Server | Microsoft Docs and find the section Truncate Transaction Log. 

Is a maintenance plan in place that checks the DB integrity? Otherwise you could get into the situation that you're backing up a defect DB over the time with the snapshots.

While server snapshots are certainly a fast way of recovery, personally, I would add a classic DB backup plan as an additional layer of security. Maybe only on a daily basis as you already have hourly snapshots. At the end, it's considering the (usually low) costs for the additional backup storage compared to the risk of data loss if your main backup strategy fails.

There are no official guidelines to backup Sage X3 but know this:

- you need to back up your x3 database - whether it is using snapshots of VM or SQL backups doesn't matter

- You need to back X3 application files for your live folder. If you have a SEED folder, you need to back up the content of the Folders\Seed directory at the same state as the data backup. Indeed, Sage X3 is keeping metadata in tables for tables and screens description notably. You need to make sure your data and application files are from the same "state" or moment if you prefer.

My advice to you: don't think about a backup strategy but rather a restore strategy. Also, make sure you have 2 ways to restore just in case your snapshots are corrupted (it happened...).

Here is an example: Start with a full backup then

- Backup SQL logs every hour if you are using full recovery model

- Backup X3 database using differential backup every day

- Do a full back up every week

- Use Robocopy to copy Folder/SEED content every day. Don't take /TRA or /tmp.

Alternately, if you can, make sure you have somewhere a "X3 SVG" backup for a third way just in case.
Last but not least, do not store all of your backup types at the same place. Make sure you have 1 in the cloud securely somewhere, or a different datacenter, etc.

Don't forget, X3 uses two databases, SQL Server and MongoDB. 

Looks like the support team wrote an article on it, "How to backup the MongoDB Syracuse database" if you are interested. 

It's important because if you are recovering to a point in time in your SQL, you'd want your point in time to match on the MongoDB side. 

Absolutely true, don't forget to do a cold backup from time to time ! This being said, MongoDB is not changing its content as often though. Thanks Bob !

We are a VMware environment with replication to an offsite replica SAN with a 15 minute RPO.  We also have a Datto appliance taking hourly snapshots local to the appliance and storing these snapshots in Datto's cloud repository.  

Our X3 vendor had me configure 3 servers for X3 - one for IIS, one for the app (Syracuse/MongoDB folder), and I for the SQL Server DB.  All 3 of these servers have hourly snapshots and VMware replication configured, but these snapshots aren't going to be at the exact same time across all 3 servers.  

Would it be a good idea to run a nightly SQL Server backup and a nightly MongoDB folder backup at the same time on these two servers to solve the guaranteed same time scenario?

I know customers who rotate the mongo log due to size growth over time as well. 

I would add this additional backup not only to have same time backups but because a) images may backup a corrupt DB b) a additional/different type of backup adds another layer of security

It would for the same reasons ul.luc mentioned in addition to be synchonized from a time perspective.