IMHO from experience with other debuggers, GDB is actually hostile to debugging at the Asm level, due to many perplexing design choices which may or may not be deliberate. Things like needing to add a superfluous asterisk when breakpointing on an address, the "disassemble" command not being able to do what it says and instead complaining about a lack of functions, etc.
Of course, visual debuggers are another story entirely, but I'm not really thrilled with them either. For example I don't recall there being a good way to say "Decode the address at rax as a WNDCLASSA" or something like that in IDA. (I'm crossing my fingers for a Cunningham's Law here.)
It is annoying though that you can't make the register display show a particular type, it only shows unsigned hex integers. If I'm tracking a 32-bit float it is very frustrating, it won't even show you alternate representations on hover...
For as good and expensive as IDA is, the UX sure is lacking.
I added support for a lot of DWARF2 way back in the dark ages of time, and hit most of these design choices.
It was basically built to support STABS (or was it DBX, i always forget).
Everything else was an afterthought.
That doesn't make it the wrong choice mind you, and lots of things have been made better or redesigned in the past 2 decades.
But to your point, it wasn't really meant for the use case of assembly debugging.
In part because assembly debuggers already existed on most OSen.
Also, because if you were using GDB, you were supposed to have both the source, and the debug info (because it was the FSF debugger)
For reference (for other readers), while I totally agree with you, disassembling at a particular address can be done via something like "x/20i $pc" ("display 20 instructions starting from content at $pc").
Something quite annoying as well is that you have to patch GDB in order to be able to use software single-step on custom OS/baremetal targets (IDA has no such issue, it is an option in their UI). GDB doesn't even honor their own remote stub protocol.