Well, i am not sure if i am the best person to attempt to answer this as i have never used Dragonfly, let alone looked at it's source but given the nature of my opinion that might be excusable.
First off i don't see a whole lot of difference between system programming and normal(?) programming. Sure at kernel level you will have access to interfaces provided by the actual hardware, which have semantics more different from what one is used to than switching from one set of library functions (API) to another and sometimes dealing with those will be the elemental purpose of the code at hand but beyond that what's the big deal? A kernel is more or less a library abstracting hardware access. A quite low level one and you don't get a ton of helper stuff to make your life easier but oh well.
With that out of the way i'd argue that the choice of NetBSD vs. Dragonfly for learning mostly comes down to: Which one appeals to you more. Sure, it can be seen as given that there will be some differences but will those differences will be that drastic when looking at the bigger picture? No, i don't think so. One will have a more elegant solution here and the other will have nailed it there. Looking at it from a learning perspective the most value you can get is probably from knowing both and understanding which is which in what situation and why things emerged the way they did (such systems grow so often times things aren't decided in a vacuum but are highly influenced by circumstances that might or might not have been fully intentional at the time when the reasons for those materialized). Even then there will be a lot of parts where it's not really possible to determine an objective "better" as it comes down to various philosophical questions.
Using homegrown solutions is pretty much an example of this as in question of this being better or worse than using non-homegrown solutions is probably best answered by a very decisive "It depends".
As you basically state yourself (NetBSD being minimal and not minimal at the same time) things are relative. If things are X usually depends on what you compare them to. In regards to minimalism most system will qualify when compared to Windows but probably not so much when compared to DOS. I'd argue that when it comes to operating systems you pretty much can't archive any form of absolute minimalism these days as the result would hardly see any real world usage.
Also i am not entirely sure what point is made by the linked issue. It seems rather random. If you look at a range of systems and ask yourself the "does system X have problems that system Y doesn't" the answer will (with practically 100% certainty) be an uniform "yes". Sure some systems will have more issues than others but that's usually more influenced by the actual manpower (be it actual developers or users providing feedback) behind those systems then by their quality or the possible lack of it.
It's kinda similar with having a LUA interpreter in the kernel (is there? i haven't seen or noticed it at all). Sure it's possible to have an opinion on (i certainly do - not my cup of tea) but in the end the mere fact that it exists itself doesn't say a whole lot. It's more about it's used or rather isn't.