Disadvantage To Using Batch?

Volume is key. At the volumes you're talking about, and with the frequency, it doesn't really matter, unless your user is waiting on the results of the batchable. Basically, there's a maximum number of records you can process per execute call, and there's usually an intra-batch delay that may last for several seconds.

This means that some Queueable that could finish in 1 second flat might take Batchable upwards of 10-20 seconds (or more, on some heavily loaded servers), plus the time needed to run the start method. This can make the experience uncomfortably slow if users are waiting on the results.

For back-end processes where timing isn't critical, choose whichever you prefer. The difference between batchable, queuable, and schedulable classes is fairly insignificant as long as (a) any of them can complete their task before the next one starts, and (b) there's no user waiting on the results of the processing.

Salesforce.com basically says the same thing: the lightweight processes uses fewer resources, so is more friendly to the servers. This is, of course, why we have governor limits. I'm pretty sure that they'd prefer that everyone ditch the batchable interface and go with Queueable, because of the obvious performance benefits that it'd give everyone in a multi-tenant architecture, but there are times when batchable is necessary, such as processing 50,000,000 rows of data.

I'd say that you should probably prefer directly modifying records in schedulable/queueable classes when designing new services, because there is a general performance benefit to the overall system, but I would also say that if your current batchable process is working, and not handling too much data, it's not worth redesigning the code to be queueable if you already have a working implementation.