tl;dr: Routers are only getting more powerful. Using them for more makes sense. Reducing the activation energy to develop FOR OpenWrt by adopting low-cost policies to make it easier to develop ON OpenWrt only makes sense.
To answer the question, the use case boils down to it being far easier to perform in-situ compilation of some sort of interesting or new feature on an OpenWrt device than it is to cross-compile it.
I'm not the only one who does this. I invite anyone with access to look up stats for how often gcc, binutils, make, and golang are installed over all platforms.
I don't think the asks are too expensive:
Asks:
- Reduce or remove the use of
sstripon shared libraries, certainly for those libraries which have -dev counterparts
See my analysis on the usage ofsstripvsstrip --stripall - Add in stubs for certain libraries to unbreak those build systems that need the existence of libpthread, libnl, librt, etc.
Cost: Four files, 32 bytes total. Can be included in gcc since they would only be used for development. - Create the policy that if the -dev library exists for a library, then its use in development is supported, so that future changes won't break them again.
- Selectively (and over time) add a few other -dev libraries. A good candidate is musl-fts, for example.
As an example of this sort of development, I've demonstrated the ability for OpenWrt to self-host. I am also in the middle of determining the viablity of using corosync and dlm_controld on OpenWrt so users can get access to shared-disk filesytems over NBD and ATA-Over-Ethernet. I think this would benefit people using OpenWrt devices for NAS.
Those are just my personal projects. Other people have others. The asks are pretty low, though, compared to the benefits.