I reckon this is probably not true? If so, is it because it keeping a counter like that up-to-date would be inefficient
Edit: I just realized I might be misunderstanding what that query does
Explain select count(*)
If you're only after a (update: really rough) rough value
Meanwhile the primary key is typically the largest index, since with InnoDB's clustered index design, the primary key is the table. So it's usually not the best choice for counting unless there are no secondary indexes.
As other commenters mentioned, the query also must account for MVCC, which means properly counting only the rows that existed at the time your transaction started. If your workload has a lot of UPDATEs and/or DELETEs, this means traversing a lot of old row versions in UNDO spaces, which makes it slower.
It's survived several HN death hugs.