Update the article there's now a section for UUID4 with rowid. It's less bad than UUID4 without rowid but it's still about 4-6x slower than UUID7 without rowid.

The reason to use it is that it skips the double lookup. A normal rowid table with a UUID primary key keeps two B-trees: the table itself keyed by the hidden rowid, and a separate index from your UUID to that rowid. A lookup by UUID walks the index to find the rowid, then walks the table to find the row. WITHOUT ROWID makes the UUID the table's key directly, so the row sits in that leaf and you walk one tree instead of two, and you don't store the UUID a second time.

The tradeoff is what the benchmark is hitting. Once the table is physically ordered by the key, a random v4 scatters every insert across the tree and you pay for the page splits. A plain rowid table keeps that churn in the secondary index, which is just the key plus a rowid, while the table itself stays append-ordered. So it only really pays off when the key is something you look up directly and is roughly sequential, which is why v7 comes back near baseline.