An event trigger fires on database events rather than row changes: on ddl_command_start, on sql_drop, on table_rewrite, and, since PostgreSQL 17, on login. They are how you audit or veto DDL, and they come with a well-known way to shoot yourself in the foot. Write a trigger on ddl_command_start whose function raises an exception, and every DDL command in the database now fails, including the DROP EVENT TRIGGER you would use to remove it. The documentation ships exactly this example, an abort_any_command function wired to abort everything, presumably so you recognize the shape of the mistake once you have made it.
event_triggers is the way out. It is a boolean, default on, settable by a superuser, and new in PostgreSQL 17. Set it to off and event triggers stop firing for your session, which is enough to let you drop or repair the broken one and switch it back on. It does not disable the triggers permanently or for anyone else; it just gives your session a database where they are not in the way.
The case that makes this more than a convenience is the login trigger, also new in 17. A login trigger fires when a user authenticates, so a bug in one can block every login, superuser included, and you cannot SET a parameter in a session you are unable to open. That is why the setting is honored from the connection string: start psql with options='-c event_triggers=off' and the trigger is disabled before it gets the chance to lock you out. You get in, fix the trigger, and reconnect normally.
None of this was available in a comfortable form before 17. The only escape from a self-inflicted event-trigger lockout was to shut the server down and restart it in single-user mode, where event triggers do not fire at all. That works, but it means downtime and a console session on the host, a heavy price for undoing one bad CREATE EVENT TRIGGER. The GUC exists specifically to retire that ritual.
So there is nothing here to tune, and no reason to touch event_triggers in postgresql.conf. Leave it on. It is the fire axe behind glass: irrelevant right up until the day you need it, and on that day far better than its predecessor, which was spelled “take the database down and boot it single-user.”