The issue seems to stem from the use of the mergo.Merge(client, existingClient) call here:
https://github.com/mrparkers/terraform-provider-keycloak/blob/d65c3b87b47fc609fe0252bf6d4a4a26fcac7f67/provider/resource_keycloak_openid_client.go#L536-L538

Since false is the default value for Bool, mergo assumes the field was unset in the client object, and overwrites it with whatever is in the existingClient object. See darccio/mergo#129.

Since the Update method doesn't know what the config was at import time, a subsequent apply updates the field to the expected value.

Because Update wouldn't respect any previous configuration anyway, would it be possible to remove the "merge with existing client config" altogether?

To avoid silently failing, a postcondition can be added to the resource. This ensures an error will be thrown when the bug is encountered:

resource "keycloak_openid_client" "example" {
  client_id   = "example"
  enabled     = false
  access_type = "PUBLIC"
  import      = true

  lifecycle {
    postcondition {
      condition = self.enabled == false # Add `&& self.<field> == <expected value>` for each field whose value is important. Of course, you should probably also use a local variable to store the target value for each field and reference the same local in this condition to ensure they are consistent.
      error_message = <<-EOT
        There is a bug with the keycloak provider that causes some fields to be set to unexpected values when `import = true`.
        See https://github.com/mrparkers/terraform-provider-keycloak/issues/1007

        This bug has just occurred. You must perform another terraform apply for the expected values to be applied.
        EOT
    }
  }
}

On the first apply, the resource is created, but fails the postcondition. On a subsequent apply, the resource already exists in the terraform state, and the update sets the field to the expected value.