もしかすると、公式ドキュメントがおかしい(?)かもしれません。

# https://firebase.google.com/docs/cloud-messaging/ios/client#method_swizzling_in_firebase_messaging
if #available(iOS 10.0, *) {
  // For iOS 10 display notification (sent via APNS)
  UNUserNotificationCenter.current().delegate = self

  let authOptions: UNAuthorizationOptions = [.alert, .badge, .sound]
  UNUserNotificationCenter.current().requestAuthorization(
    options: authOptions,
    completionHandler: {_, _ in })
} else {
  let settings: UIUserNotificationSettings =
  UIUserNotificationSettings(types: [.alert, .badge, .sound], categories: nil)
  application.registerUserNotificationSettings(settings)
}

application.registerForRemoteNotifications()

このような記述がありますが、調査を行ったところ

let center = UNUserNotificationCenter.current()
center.requestAuthorization(options: [.alert, .badge, .sound]) {granted, error in
    if let error = error {
        print(error)
        return
    }
    if granted {
        DispatchQueue.main.async {
            UIApplication.shared.registerForRemoteNotifications()
        }
    }
}

このように requestAuthorization 内で
registerForRemoteNotifications を呼び出す仕様に思えました。

またswizzlingと呼ばれるメソッドを差し替えるテクニックにより
device tokenのセットをFirebase側で行っているが
それがiOS13周りで壊れたのかもしれません(?)

swizzlingをoffにする設定もあります。
swizzlingは出来れば避けたほうが良さそうな雰囲気もあるためOFFにした。

※ 今回あげた2つの原因に対して同時に2つの対策を行ったため切り分けは行っていません。

上記の2点の対策を実行したところ無事にPUSH通知が飛ぶようになりました。

こちらはプログラミング相談サイトMENTAでご相談頂いた内容です。
PUSH通知が飛ばないなどのにお困りでしたら気軽にご相談ください。

https://menta.work/?nic=owAl5EbX7N3uIo7i&ref=ni
https://menta.work/plan/88