TBH I am not an expert in these things (i.e. Drupal security) but I know my way around TurnKey fairly well... So I'd like to think that I can provide you with an educated opinion but it isn't going to be conclusive nor should it be considered exhaustive or unquestionable.

So with the disclaimer out of the way; firstly I would suggest that you follow the advice of Drupal themselves. In other words launch a new (clean) instance of the Drupal7 appliance and restore your website to a backup from before 15 October 2014. Once you have done that then immediately update Drupal (or at least apply the security patch).

So to specifically answer your questions; restoring a pre 15 Oct TKLBAM backup would probably be adequate but would not provide 100% piece of mind. This is because as you state it is a selective backup and if files not included in the backup have been tampered with then they will remain untouched (and hence still compromised). Because of the way TurnKey is set up and TKLBAM is configured on a Drupal7 appliance it is probably likely that any files that may have been tampered with would probably be replaced, but personally they're not odds I'd like to gamble on (but then again I'm not much of a gambling man...)

I would patch Drupal immediately after restoring your backup not before. This is because your backup will probably contain files that need patching (that will overwrite files you had patched). I suspect that answers your next question, but to directly answer it: restoring a current TKLBAM backup would almost certainly carry over any infected files or data (assuming that your server had been compromised).

So the unfortunate reality is that the only way that you can give yourself the absolute best chance of not hosting an infected Drupal site is to restore your old backup. However, you mention snapshots rather than TKLBAM backups. TBH that confuses me a little as they aren't the same thing. A snapshot is basically a clone of the entire OS (that can be launched instantly as a new server - servers running on an EBS backed TKL Hub plan support this; as does many hypervisors/virtual computer software). Whereas a TKLBAM backup is a selective data backup (that needs to be restored to a server that exists already). Essentially it doesn't make that much difference for the purposes of my advice in this situation though, either way go for a pre 15th Oct backup...

So following being the bearer of bad news I also suggest that you read through the link I gave above, plus other relevant Drupal info: the original Drupal announcement and "Your Drupal site got hacked. Now what?".

Other thoughts that spring to mind:

Enabling daily TKLBAM backups. By default it will do monthly full backups and daily incrementals and keep them all forever. If you're worried about backup size growing too much, limit it to only keep a limited number of backups (this relates to full backups). Alternatively if storage usage is not such an issue for you then I'd recommend reducing the full backups to fortnightly (rather than monthly). This will make restores quicker and reduce the chances of data corruption. It is unlikely in AWS S3 storage but still possible and by reducing the timing between full backups you also reduce the backup chain length (the incremental backups rely on a chain of all the previous incremental backups back to the last full backup).

Also I would argue for a monthly (or more often) regime of backup testing (i.e. test your backups monthly by restoring to a clean instance). Whilst I have found TKLBAM to be impressively reliable nothing is ever perfect and IMO an untested backup is only marginally better than none at all. Murphy's Law dictates that the likelihood of an untested backup not working when you need it are high!

And finally a note about Drush. In case you weren't aware TurnKey Drupal7 has the awesome commandline tool 'drush' installed. It makes things like updates and installing new modules and themes really easy! If you are unfamiliar with it there are plenty of great resources online; e.g. here, here or here.