Martin, I agree with you.
The things that make asm debugging with GDB "inconvenient" is that the data one wants to look at is either, not available, or it takes a fair amount of work to get to it, e.g, multiple memory windows, registers always visible and in hex. The watches window in VS is really convenient. Having symbols for the system DLLs is quite often very convenient too.
I haven't "promoted" (so to speak) the VS debugger because, there are some significant downsides to using it. For instance, quite often the assembly code and the source are not in synch, that can be a real problem for some people. Many subroutine names have a generic "call publicxxxx" which is not very informative. It's useful for someone who is comfortable with raw assembler but, could likely be very frustrating for someone who isn't.
The cv2pdb is a nice utility but, there is room for improvement in it. I've thought about improving it quite a few times but, MS makes it "laborious" to develop and test a utility of that kind because of the many dll dependencies. It really doesn't make it easy for a utility of that kind to operate properly.
Ideally, there would be a full fledged, graphical, standalone debugger 'a la VS2017' available for FPC but, that's no "breakfast" project.
I'm just thinking out loud. I think the debugger is the "achille's heel" of the FPC/Lazarus environment and, it isn't one that is easily and quickly fixed. That said, the current implementation is very usable and often sufficient.
If there was a debugger like VS2017's available for FPC/Lazarus, I doubt I'd write another line of C.
I miss SoftICE... really miss SoftICE. I still have a Windows XP installation with SoftICE and Delphi2. SoftICE understood Delphi2's debugging symbols which makes it possible to debug at source level while having assembly and all the power of a system level debugger at one's fingertips. That's nirvana... can't give it up, even though now it is rarely genuinely useful.