The big advantage of blobs is that we can add more stuff without migrations. Adding new properties to some tables (like HarbormasterBuildLog, recently) potentially means hours and hours of downtime for large installs.

The big advantage of real columns is that we can query on them (and add keys, and join them, etc).

Decoding JSON is normally very fast, and I believe there's no meaningful inherent performance difference between columns and JSON blobs in most cases. I haven't specifically benchmarked it recently, but I can't recall these JSON decodes ever showing up in a profile while doing performance work. JSON is slightly less space-efficient (e.g., column names are repeated) but this usually isn't an issue (we've never hit a case where we optimized a table's size by moving away from JSON, at least that I can recall offhand).

Increasingly, a lot of objects tend to have their major properties as columns (when we need keys, constraints, etc) and then a $properties-type field for whatever other random stuff turns up.

In this case, it's (almost certainly?) clear that nothing will ever want to query/join/constrain mailKey since it's a random secret, so the advantages of column storage are moot. The other two potential things we know about that we may want to store here in the future ("Must Encrypt" state, "Original Subject") also (almost certainly?) don't need to be queried. This table may also become large-ish (the rows are small, but it may have 1 row per object that exists in any other application) so migrations might be expensive in the future. Thus, a bag-of-JSON-properties felt like a better fit than a dedicated column.

And just out of curiosity, why do we prefer blobs of JSON vs tables with (objectID, propertyName, propertyValue) columns?

Oh, this is another advantage of the JSON blobs: with reasonable frequency, we use them to store maps or lists.

So we could use an <object, name, value> table, but then the value would need to be JSON ([1, 2, 3]) anyway, or we'd need another <propertyID, uhIndex?, value> or something, and then another one under that if the lists are nested. Basically a big mess that is either super hard/complicated or just ends up storing a lot of JSON anyway.

I don't want to migrate things passively one at a time because I think it just makes things more complicated (what's in the table is less clear/knowable), and the ultimate migration needs to hit everything anyway since we can't guarantee that passive migration will ever complete.

I don't think it matters too much in this case, but I think doing a trickle-migration tends to make it harder to make changes here (e.g., if nothing else, the table is larger) without any concrete benefits (at least, I can't think of any).