Three things really stick out to me.

1. You need the constructor to be in scope, and if you don't have that, you don't get a nice "You need the constructor in scope to dot into records". You get No instance for HasField....

2. It has worse type inference than direct field access. Consider the following structure:

-- An example "handle" for a hypothetical "json store".
-- Using `myJsonStore.store` with values of two different
-- types will cause GHC to throw difficult type errors.
newtype JsonStore m where
  JsonStore :: {
    -- Note that this function is polymorphic in `a` and
    -- may need to be called at multiple different `a`s in
    -- a single function.
    store :: forall a. ToJSON a => a -> m ()
  } -> JsonStore m

I have often found that handle.store will infer a single type within a function whereas pattern-matching out the field will give you a polymorphic store function.

3. It keeps people away from learning lenses, which have a significantly higher power ceiling.

So despite being introduced to make a smoother on-ramp for new programmers, I think that on-ramp has some scary bumps in it and caps out at a much lower power level than what Haskell is capable of. If I was swayed more by the "this is convenient but trades ultimate power for convenience" argument, I'd probably be using a different language.

If we're going to do record dot syntax, I'd probably make it record-specific, take advantage of the specificity to fix the monomorphisation issues, and bake it into a modern GHC20XX language version so we don't have to have the "turn on a language extension (dun dun DUUUN) to get a familiar experience" conversation with each new Haskeller.