Since there will always be just one row in the site_stats table, the "ss_row_id" column should be completely removed. It is pointless.
@GeoffreyT2000 At a more basic level, it might be more appropiate for this data not to live in its own database table. Or to significantly alter the table to become key/value based (e.g. instead of one row with columns for each key, it could have a key/value column only with rows for each pair).
|row_id PRIMARY KEY||total_edits||total_pages||users||active_users|
|key PRIMARY KEY||value|
However, as long as it is column-based it is best to have a primary key. Otherwise, it becomes considerably more difficult to correctly perform insertions or updates on the table. Without an ID column, the only way to retrieve the data would have to do an unrestricted query to SELECT everything, and limit it to a single result. If for some reason multiple rows do exist in this table, at this point you would have no guarantee which row is returned, and there would be no good way to ensure a change in an UPDATE query will affect the same row returned by the SELECT query.
With an ID column, this is resolved by locking on the ID. In this case, we enforce there only being one row by using the generic ID "1", or which ever ID is selected by the database backend.
A wider overhaul for the site_stats table to become key/value pair based seems reasonable, however given how small and simple this feature is, I suspect it might not justify the required effort to make a breaking change to this table only to rid it of an awkward primary key.
It's interesting that something so simple can apparently offend someone so much...
There's certainly scope for some use cases to make use of this; it could be possible that a wiki farm or similar, that used shared tables could reuse this table, rather than having multiple, for example
Propose to decline this task, unless we mark it as a low priority task to overhaul it completely as per Timo?
There's an argument to be made for supporting multiple wikis in the same table, but in practice we don't support that and the primary key would need to be something like wfWikiId() anyway. Timo's idea about making it key/value based (and in which case we'd possibly want to extend the SpecialStatsAddExtra hook to allow writing back to this table).
But both of those aren't what's being asked for here. The column hurts nobody and has some upsides that Timo mentioned.