Anywhere that an array of SObjects is queried - e.g. your Select Id from Contacts - those data rows are included in the response and so have to be transferred and consume a bit of heap.
An aggregate query allows the count to be established inside the database and just that number to be returned. It also signals your intent more clearly which is important to help others understand your code in the future.
So yes sometimes you can use either approach, but aggregate queries are worth learning about so you can apply them when they are by far the best choice e.g. large row counts or other operations such as these are needed:
- AVG
- COUNT
- COUNT_DISTINCT
- MIN
- MAX
- SUM
or more exotic operations such as GROUP BY ROLLUP.
(In the past counting via aggregate queries was still subject to the 50,000 row governor limit but that is no longer the case.)
Using aggregate queries gets the work done close to the data where the work can be optimised. To give an example, we had some complex business logic that involved many rows being queried followed by some fairly complicated Apex code iterating over those rows. Not too surprisingly, this hit CPU governor limits and heap governor limits for the more extreme cases. Refactoring this to do the part of the work that was "per row" into an aggregate query removed those governor limit problems. (OK we were lucky that the logic could be restructured in this way; certainly not always possible.)