Looks like we lose the validation that the metadata in the payload was the unescaped literal "$ref". Do we care?

Hmmm not really, unlike NameEquals; EscapedNameEquals will compare against the raw bytes, i.e. it won't unescape the name.

Could another approach be to intercept the call to the Object/JsonElementConverter (when the ref handling feature is on) and just read the $ref metadata directly?

Yes, but we would have to create a copy of the reader that we would need to throw away if the payload doesn't met the required conditions (being an object, contain only the $ref property). Since this is an edge case, I think this approach is cleaner.

Why was this line deleted?

It is still there on line 72, I added the condition if (options.ReferenceHandler == null || !GetTypesNonRoundtrippableWithReferenceHandler().Contains(type)) to skip it given that it won't work if the root type uses object type elements and has a $ref object.

What's a minimal code sample to highlight this behavior?

key1 will be parsed as a JsonElement and when key2 tries to look for the reference, it will not find it.

using System;
using System.Collections;
using System.Text.Json;
using System.Text.Json.Serialization;

public class Program
{
  public static void Main()
  {
    var foo = new Foo();
    Hashtable h = new Hashtable();
    h.Add("key1", foo);
    h.Add("key2", foo);

    var opts = new JsonSerializerOptions();
    opts.ReferenceHandler = ReferenceHandler.Preserve;

    string json = JsonSerializer.Serialize(h, opts);
    Console.WriteLine(json);
    // {"$id":"1","key1":{"$id":"2"},"key2":{"$ref":"2"}}

    Hashtable copyOfh = JsonSerializer.Deserialize<Hashtable>(json, opts);
  }
}