So it seems your main concern is the performance penalty imposed by AUTOINCREMENT, where the post you've linked as describing your problem mentions performance only in the context of using INSERT OR IGNORE vs. a conditional INSERT on a SELECT:
MUCH faster than checking the existence with
SELECT ...and do anINSERTif needed.
While AUTOINCREMENT is indeed more costly, note that the potential performance gain would be hidden away from the average user by the fact that gravity swapping only happens after the new db has been fully populated, and only once a week (making it one of saving CPU load rather than actual time).
As gravity rebuild times would vary greatly among different installations for both a user's configuration choices and their choice of h/w hosting Pi-hole, it'd be hard to give any actual numbers as to possible performance gains, but it would seem that you could expect improvements in the high one to low two digit percentage range (say 9% or 10%).
That's not entirely true:
A user may delete the adlist containing the domain at any time.
We recently discussed that it may be necessary to delete orphaned domain entries when the respective adlist was deleted.
That doesn't seem like a point against your suggestion per se at first glance, but when considering it in the light of another one of your (indirect) suggestions of dropping foreign key constraints, then dropping AUTOINCREMENT may result in domains being randomly assigned to an adlist when the conditions of reusing an existing rowid would be met.
Granted, that would be very unlikely indeed, but when weighing database integrity against potential performance gains, I'd personally tend to opt for the former, unless performance benefits would be both substantial and relevant.
That would be a development choice, of course, and as gravity is by default rebuilt once a week, somewhat weakening those potential detrimental effects, this may indeed be something that they'd want to consider.
Thank you for your recommendation.