This is the view that you need to check:

select n_live_tup, n_dead_tup, relname from pg_stat_all_tables;  

The data in pg_stat_user_tables is not transactional. It is reset to zero/NULL whenever the system crashes or has an unclean shutdown (and can also be reset manually). That has presumably happened.

The high freepercent reported by pgstattuple would seem to indicate that the table has been vacuumed at some point, now forgotten about. You could check the freespace map to make sure PostgreSQL knows how to find this free space when it needs it.

Those two columns are the result of

SELECT pg_stat_get_live_tuples(c.oid) AS n_live_tup
     , pg_stat_get_dead_tuples(c.oid) AS n_dead_tup
FROM   pg_class c;

Representing the number of live and dead rows (tuples) in the table.
Find those functions in the manual.

Dead rows are deleted rows that will later be reused for new rows from INSERTs or UPDATEs (the space, not the data). Some dead rows (or reserved free space) can be particularly useful for HOT updates (Heap-Only Tuples) that can reuse space in the same data page efficiently. More on H.O.T.:

• PostgreSQL Initial Database Size
• Release notes for PostgreSQL 8.3 where this feature was introduced.

Dead rows can be removed by VACUUM FULL (or plain VACUUM if it gets lucky) or similar operations on the table, thereby shrinking the physical size accordingly.

Whenever a row is deleted or updated, the old row version becomes invisible to all other transactions starting after the transaction has been committed - with default READ COMMITTED transaction isolation. The row is completely dead as soon as there are no more uncommitted older transactions. That is necessary for PostgreSQL's MVCC model to handle concurrency.

Those are just statistics. You need to enable statistics collection in postgresql.conf if you want them to be updated automatically. track_counts should be on by default, though. Bear in mind that statistics are not updated instantaneously.
More about the statistics collector in the manual here.