◇ Could this help me?
Yes for the headline, with the substitute understood properly. The core instruction is correct and important: a mail account password should never be typed into a third-party application, because that account is the recovery route for everything else, and an application-specific password is genuinely better since it can be revoked individually without touching the main credential. The part the video leaves out matters, though. An application password typically grants full mailbox access and bypasses two-step verification, so it limits blast radius after a compromise rather than limiting what the application can reach, which means the delegated sign-in flow is strictly better wherever it is offered. The caption gets this right by scoping the advice to custom connections that have no delegated option. General practice, and the complete version is: delegated sign-in first, application password only when there is no alternative, revoked when the integration is retired.
Go through every integration I have connected to my mail account and tell me which authentication method each one actually uses: a delegated sign-in flow, an application-specific password, or my real account password. For anything using my real password, tell me how to replace it immediately. For anything using an application password, tell me what that password can actually reach, confirm whether it bypasses my two-step verification, and whether a delegated option exists that I should be using instead. Then show me where to review and revoke generated passwords, and help me remove any that belong to tools I no longer use.