Anything with a learning curve steeper than "throw your files in a Dockerfile and call it a day" unfortunately tends to be considered "not sane". There is a whole market when it comes to making new tools for people who "don't have the time to RTFM". And then for tools helping to use those tools.
IMO, start small, maybe with a RPi. Possibly Nvidia provides layers for the Jetson (I haven't seen that), but in my experience the risk is that those layers are super complicated (and fairly messy). I think it's better to learn how Yocto works first, rather than learning how to hack the layers provided by the manufacturer.
Also it helped me to learn a bit how other distros are built: I tried Linux from scratch, then got interested in Alpine, and then in how PostmarketOS got started based on Alpine tooling.
After all, a distro is "just" a bunch of packages, which are archives containing files that get decompressed in the right place. Yocto provides tools to create those packages (just like mainstream Linux distro). What Yocto adds on top is tools to manage cross-compiling (toolchains, a way to create an SDK, etc) and a system of layering that helps organizing them ("those packages go specifically with the RPi, so I will put them in a layer called "RPi" and I will call that a "BSP"", etc).
Don't get me wrong, there is quite a lot. But there is no magic, the goal is always to create packages that will put the right files in the right place :-).
I just started learning Yocto a few weeks ago, and just shipped my first embedded image. Here are a couple of learnings and thoughts:
1. Start with an empty image and build your way up. There can be some cross-effects between packages depending on what you exactly do, it's a lot easier to debug if you go step by step. The base image recipes are all listed in the documentation, start with one of them.[1]
2. Lean into Bitbake and the whole thing. The more you try to fight it, the more it fights back. I liked this guide as a starting point to get a feel for it.[2]
3. Find a way to quickly iterate on your images. Nothing worse than losing your train of thought! Since I wanted to include update functionality I added swupdate, which integrates reasonably well with Yocto[3] - although the documentation is a bit difficult to read at times. But being able to simply push an update through WiFi is really, really nice.
4. If you do some lower-level stuff you'll inevitably need to create configuration fragments. This process was REALLY opaque to me. Say you want to set build options for U-Boot - you'll have to: 1) run `bitbake -c menuconfig u-boot` to open the config menu; 2) when closing the menu, you save the configuration in the default location; 3) then you run `bitbake -c diffconfig u-boot` to generate a config fragment; 4) you copy the config fragment into your recipe-append-folder and add it to the SRC_URI variable; 5) you run `bitbake -c clean u-boot`. When U-Boot is built the next time it will apply your configuration fragment to the build process.
These were the most important things that came to mind. Hope they help, and good luck on your journey! :)
Word of warning - I don't know how much you've looked into it yet but depending on your needs from Jetson the Nvidia stack gets really complicated really quickly.
I know people have frustrations with Nivida supplied Jetpack but when you end up trying to figure out how to roll your own support for TensorRT, DLA, cuDNN, etc (on ARM64, of course) many people bail and run screaming back to Jetpack.
(To be clear: I really like Yocto)