Good question. According to the Performance Best Practices document, the platform optimize the number of fields to be retrieved in aggregates (just it did with Simple Queries), but I'm not sure if no field is fetched the platform "clean" this aggregate query execution. Anyway, I agree that the platform should know that it just needs to execute only the count.

just to update you all. I've been doing tests on this with our DBA, and here's what I've found:

Using an aggregate to fill a tablerecord, the Platform is optimizing to get only the needed columns. The executed SQL is something like "SELECT col1, col2, null, null, null, col6, from table..." This we all already knew

Using an aggregate and get ONLY the count (Aggregate.List.Count), it will execute 2 queries. The first is "SELECT null, null, null, null, null, null from table..." and the second is "SELECT count(1) from table...". Yet, currently you can use "Group By" in aggregates, so you can you the Count by selecting the unique identifier from the query.
Then you can get the count with Aggregate.List.current.count

So, if you don't have weird filters that need to be done in Advance Query, you can use this Group By to get the count, otherwise, use advance queries.

Of course, if you just want to know if the query returns data or not, just use the empty property...