The 65816 is an enormously frustrating chip. Parts of it I've fallen in love with, like the stack stuff, and it's really, really hard to go back to 8-bit after using a 16 bit processor. Others I absolutely hate -- the decision to have a mode switch and use the same opcodes for 8 and 16 bit was, ahem, debatable and the new mnemonics are bad enough I ended up creating my own. It's a real missed opportunity, and I wish somebody could convince WDC to go back and do a clean 16 bit version of the 65816. There are basically no other 16 bit processors out there in this package, AFAIK. In few years, it will either be the 65c02 or directly up to a RISC-V variant.
Still, as BDD said, the 65816 great as a hobby project.
For software, the practical barriers are that there is no easy to use emulator like the py65 for the 6502 you can just sit down and play around with; the same goes for assemblers. I ended up writing my own of both, which was a great experience in itself, but they're not really "easy to use" by anybody's definition (one is in Forth). I have back burner projects for both a new emulator (in Go this time, to force me to learn golang) and an assembler (in Python, to learn how to write real lexers, parsers etc). In that respect, the 65816 is fantastic because it has all kinds of weird edge cases -- the Forth emulator finally helped me understand how to use DEFER, for instance.
For hardware, the chip needs more complicated memory signals, but I think the main barrier is that there isn't a simple bare minimum reference design out there like Garth's for the 6502. If we had something like that, it would be a lot easier to say to yourself, dude, I can totally do this, and then things would positively feed into themselves, even after you found out you were actually in over your head. By then, as a lot of us know, it's already too late.
Another way of dealing with the 65816 I have thought about would be to create a bytecode interpreter for it, that is, put a thin software layer over it to make it more accessible. That would make it a better target for high-level languages. PLASMA went this way with the 65c02, but it is a bytecode stack machine, and I think a bytecode register machine would be the better, because faster choice: Those great stack instructions of the 65816 would let you access virtual registers with very little trouble. It's on my list, but then again, my list is very, very long by now ...
Anyway, I haven't regretted any of my time with the 65816. Go for it.