If I remember correctly, way back in the early noughties when I was writing ecommerce sites and the 3-digit CVV was introduced, the instruction was that it was never to be stored anywhere in your DB, on pain of some kind of nastiness to your merchant account. I presume (but don't know) it's also not stored in a machine-readable format on the card.
Thus, the extra level of security this provides is not to turn a 16-digit number into a 19-digit one, but to guard against your card number being usable if a database where it's stored is compromised (quite likely at the time, having seen the sort of shoddy code being rushed out back then) or your card is skimmed.
So, in theory, if a card number is presented with CVV it is more likely that the person presenting it has (access to) the physical card, and less likely that they're using a card number stolen from somewhere.
I do recall having to tell coders who hadn't read the documentation that the CVV wasn't to be stored in the DB, so I'm assuming that there are various implementations out there that do store it and thus neuter it as a security measure - it's a slightly brittle solution in that respect.