gdb is not supported on M1 Macs; you can instead consider using lldb.

That's because gdb is not yet out for Apple silicon (ARM architecture). In fact, neither is gcc. If you run gcc --version, you will see that in fact your mac is aliasing gcc to clang (Apple clang).

What brew is telling you is that you cannot use gdb for natively compiled code. What you are using, that is aarch64-elf-gdb, is a debugger for cross-platform development. In other words, Apple mac users developing for Linux, writing elf binaries. Obviously, you won't be able to use those binaries on your mac.

Addendum: The other answer is correct about one thing. Your best bet now for native binaries is LLDB. But you will have to learn slightly different syntax.

You will require a build of gdb not only configured for the correct architecture, but also object file type: remember that MacOSX/Darwin uses MachO object files where as GNU/Linux systems use ELF.

When using gdbserver, gdb is run on the development host, and reads executables and libraries in order to build a symbol-map corresponding to the target. It's for this reason that the gdb that Apple ships - which is built for Darwin and MachO binaries - doesn't work.

As for why things are as they are, this is an architectural limitation of gdb, binutils and incidentally gcc - all of which can only ever handle one target environment at once.
With remote debugging scenarios, there is often a need minimise link traffic and target memory foot-print. Remember, the comms link is sometimes a low speed serial-line. For this reason, as much as possible is done on the development host with gdbserver transacting very low-level operations.

Building a cross-gdb environment for MacOSX shouldn't pose any particular issues.

In order to run and debug your AArch64 executable, you (in general) need to run it on an AArch64 machine, or in an AArch64 emulator.

You might have some setup where qemu more or less transparently emulates aarch64 binaries for you - but that doesn't work quite as transparently for the debugger. In general you can run the debugger on one machine, connected over a network to a debugging server on a different machine, allowing you to debug a process running on the machine with the debugging server.

The guide you linked shows how to set up qemu to allow it to transparently emulate binaries as you execute them. That guide only shows executing, not debugging, but it has got a link "Debugging using GDB" that points to https://ubuntuforums.org/showthread.php?t=2010979&s=096fb05dbd59acbfc8542b71f4b590db&p=12061325#post12061325, where it is explained how to debug a process which executes within qemu emulation. This essentially amounts to the same remote debugging with a debugging server as I mentioned above.

The essential bits of this post is this:

# In a terminal
$ qemu-arm-static -g 10101 ./hello

# In a new terminal
$ gdb-multiarch 
(gdb) target remote :10101
Remote debugging using :10101
[New Remote target]
[Switching to Remote target]