Use a custom table for a view counter. This is faster, easier to write, and it has fewer side-effects.
Post meta queries are rather slow. The information is stored in a way optimized for average post handling, not for custom sorting or many write accesses. Also, all post meta values are fetched each time someone asks for any field. Your data will use resources even when they aren’t needed.
Sooner or later you might want to count archive views too, multiple images on one page, or downloads of archive files with more than one file. Where do you want to store that? You have much more freedom with separate tables: they are easier to extend, you can add or remove fields, tables or indexes.
Other plugins might do unexpected things with your data, so you cannot rely on it anymore.
An example: In Multilingual Press, when someone creates a translation of an existing post, I take all post meta fields (except some known built-ins) and copy those over to the other blog. I have to, because otherwise many plugins would break. But your plugin would get a wrong counter now: The new post has an incorrect view count before anyone has ever seen it.
You can protect your fields in Multilingual Press, but in other plugins, that might not be possible, or you just don’t know they exist.
I have also written a small blog post about this decision with more arguments: How to store my custom values?
See also this answer: Post meta vs separate database tables