You're comparing apples to oranges.
The Steam Deck is, fundamentally, a PC. PC software is written to run using "some" of a PC's resources, because PCs have a bunch of extra resource "headroom" for running userland software plus a bunch of other junk on them at the same time. You can run a game in debug mode, within an IDE, within Windows, on a Steam Deck. And maybe also OBS to stream yourself doing that!
The Switch — and all other game consoles ever made thusfar — are embedded systems: systems designed to run software in such a way that the software can make use of 99% or more of the system's hardware resources (because, per the unit economics of such systems, that's the only way to make the system's low per-unit BOM, translate to good perf for the software.)
Also, unlike with PCs, embedded systems can give a developer performance guarantees — a number of CPU cores, amount of RAM, etc. that will always be 100% dedicated to running your software, with even hardware interrupts being offloaded somewhere else. And the platform will be extremely uniform, with all retail units having (at least) those same numbers. (Though there may eventually be a revision of the hardware that bumps the guaranteed resources up for software that opts into that — see e.g. how the Gameboy Color runs Gameboy games, or the "New" 3DS, etc.) So, unlike with a PC, when writing embedded software, you can and should write it to use "all the resources" — to "wastefully" spend memory caching whatever you can, run background logic to pre-compute things, etc., so that your software can get the best realtime runtime perf. It's not like anything else is running. Take the Unix idea of a process being nice(1), and invert it.
This means two things:
1. when a game is running on a retail device — if you've developed it following best practices — then there's no extra room for anything else to be running. Your software, by design, hogs everything. The OS shrinks down to just running on one e-core of one accessory CPU (and on older consoles, gets terminated altogether, with the user software instead being expected to keep the hardware going using an exokernel library provided as part of the SDK.) There's no room to run an IDE or debugger. So retail devices fundamentally can't be used to develop games in such a way that they "mirror production" — to have the room to develop your game on such a device, you'd have to somehow build your game to use half the RAM and CPU it usually uses — but only sometimes. Which is likely impossible, for most software architectures; but even if it were possible, you'd no longer be mirroring production.
2. even with a devkit — essentially these days just the same hardware but with double the RAM to fit a debug build of the game (both for the debug symbols, and so that it doesn't need to take two hours to LTO the executable each time you rebuild like it does for building retail) — you still need a host PC, because you want development to mirror production at least somewhat closely, and that means that you can't be spending half the CPU budget on a userland debugger + telemetry. Instead, devkit hardware has a hardware debugger + telemetry, that feed one side of a USB-serial connection to a host PC, where the other side is a special IDE that knows how to talk to such a setup.
None of this is unique to game consoles, mind you. You do the same thing to develop for an Arduino, or a wireless router, or a smart watch, or your car's infotainment system. "Tethered hardware devkits that externalize the development environment so the embedded software can expand to fill the device" are just how embedded systems engineering works.
---
And yes, embedded-systems hardware ecosystems also often involve "QA" or "tester" units, that are basically retail units that either allow you to run [the ecosystem's specific, often proprietary] media containing unsigned code; or at least, allow you to install a specific signing key and then run media containing code signed by that key.
So you could, in theory, do your development by building for QA units.
(That is, you could, if you thought that printf debugging with two-hour iterations is the be-all and end-all of development cadence.)
Homebrew embedded-systems tinkering communities tend to ignore such systems, though, mostly due to the requirement of burning the media. Even when the media isn't proprietary, it's still often something like a surface-mount eMMC flash chip, where the embedded-systems vendor expects you to be able to program that and put it on your QA board (and will, of course, point you to their hardware support partner who will sell you a programmer for it.) While there are many hardware hackers among Homebrew people doing fun reverse-engineering attacks, there are few true Electronics Engineers in the homebrew scene who have these sorts of Shenzhen-parts-store-looking industrial test-equipment labs in their basements. The average homebrewer doesn't even own an oscilloscope. :)
It's just easier to either work with true dev kits (where all you need is to "convince" the thing that you're authorized to feed it software over the serial tether); and/or to reverse-engineer and exploit your way into a retail unit, such that you can then feed it software through some channel that is attainable for the average dev (usually, these days, that means getting the system to launch software from an SD card that was supposed to just be there to store state data.)