If you decide to run testing, be aware that while testing does get updates that address security issues after those updates work their way into testing from unstable, it does not explicitly get security updates.

Pinning some security sensitive packages to stable or unstable might be worth considering. E.g., if running testing on a client, pin firefox and extensions to stable + stable-security (note, globbing works too):

  /etc/apt/preferences.d/firefox:
  Package: firefox-esr
  Pin: release a=stable
  Pin-Priority: 999
  Package: firefox-esr
  Pin: release a=stable-security
  Pin-Priority: 999

  Package:  webext-ublock-origin-firefox
  Pin: release a=stable
  Pin-Priority: 999
  Package:  webext-ublock-origin-firefox
  Pin: release a=stable-security
  Pin-Priority: 999

The above priorities will not downgrade to stable from testing if the packages are already installed. To downgrade priority needs to be >= 1000. See 'man 5 apt_preferences'. If priority >= 1000, probably best to only do that temporarily, then adjust to lower to prevent setting a landmine for your future-self.

If there are only a couple things you want to update to newer versions that are not in backports, you can just run stable, and pin those packages to versions in testing or unstable (but only if those packages pull in no / only a few dependencies not used by other packages). If you add e.g., testing/unstable sources to a stable system, add a catchall pin to force those packages to a low priority by default to prevent accidentally updating your entire system e.g., for sid:

  /etc/apt/preferences.d/sid:
  Package: *
  Pin: release a=unstable
  Pin-Priority: 10

Pinning without thinking can result in a broken system. But, I'm typing this on a box running testing (I guess stable, as of today) with packages pinned from Bullseye, Sid, and experimental and I've never had worse issues than an update being blocked due to dependency version conflict which was easily worked-around by pinning another package/removing or downgrading a pinned package; I run unattended-upgrades on all my boxes too. But, my hard rule is no scary deps e.g., a diff version of libc being pulled in, no deps shared with other packages that I would not want to have to pin to the same release (e.g., shared with any package with tons of deps itself), and no package that wants to pull in a lot of deps regardless of how benign they appear.

Just to add - I think the backports repositories don't get enough attention when this occasionally comes up.

Trying to run a mix of stable and testing packages can be a pain as occasionally a package you want to bring in from testing will try to bring with it new system libraries, which in turn often conflict with the "stable" versions of packages (so you are forced to move a lot more of your system to "testing" packages than you originally wanted to fix this).

The key advantage (at least for me) of using the "backports" repositories is that it avoids this - packages are compiled against the "[yourrelease]" system libraries.

Just to correct the most glaring mistakes:

Ubuntu is based on Sid (Debian Unstable).

You can download Debian installers for Testing.

Usually nothing on Testing crashes, as such severe bugs are considered blockers to move a package form Unstable to Testing. (Of course once in a few years something slips through the testing period in Unstable. But it's than usually repaired within a few hours.)

People are running Sid. (Even I personally wouldn't recommend it.)

But one point of the parent I strongly support:

Debian's web page is a mess. I'm using this system for decades but still don't find anything on the Debian page without the help of some search engine. Also, when I need Linux related documentation I go to the Arch Wiki (and sometimes to the Gentoo docs), even as a Debian user. OTOH, you only seldom need docu, because Debian "just works" for the most part.