Just to chime in quickly with some relevant experience from another game:
Towns has the kind of priority system described here, where tasks can be given individual priorities on a group-by-group basis (including the default “no group” group, although not on a per-townie basis.) I don’t know what the behind-the-scenes looked like, but from a modding perspective it was relatively simple to configure from within the data files (although as a general rule, Towns is more simple to mod than Stonehearth is.)
The big issue with the system, IMO, was that most players didn’t use it or really understand it. Some of us who did dig into it found it absolutely brilliant, and it could give complete and granular control over who did what (e.g. give one townie priority to cook food and make all other jobs not considered important to them, so you could designate full-time chefs and then have everyone else effectively ignore cooking jobs.) I reckon that’s partly because the effect of a system like this isn’t immediately obvious/intuitive – setting the priorities is only part of the story, you also have to have your infrastructure set up correctly if you want the ideal/imagined outcome of your workers never running off to do random faraway tasks when there’s a better task to do nearby.
So, what lessons can be learned from the example to help improve a potential adaptation for Stonehearth? Well, the big one is to include either tooltips or some kind of tutorial (introductory mission?) which will explain the system to players and show how it interacts with their other decision-making tools. If players bump the priority of hauling to the top of the list but that doesn’t speed up hauling (e.g. because hearthlings are too busy finishing off their existing queued tasks, or because the hauling tasks keep getting assigned to slower hearthlings with low Body scores and/or speed debuffs), then it looks like the system is broken/does nothing. Considering the level of micro-management that such a priority system can introduce, some players will need a good incentive to dig into it.
Another lesson to be taken is, IMO, “work groups” (think soldier parties, but for workers) can be a very effective middle-ground between micro- and macro-management. This obviously requires another layer of system infrastructure to be modded in, but I believe that should be very possible. Stonehearth has the advantage over Towns that its Hearthling Therapist UI is more granular and accessible than Towns’ citizen context menus, so I reckon that Stonehearth can handle the extra options without becoming impossibly complicated and intimidating.
A third lesson: no matter how many options you give the player, they’re going to want more (the most popular tasks and priorities mod for Towns was one which broke every single action down into its own priority, LOL!), so I wouldn’t suggest worrying about adding too much complexity – players will mod that in themselves. This seems like a perfect candidate for ACE’s “horizontal expansion” way of doing things: give players the functionality and, eventually, someone will run with it and add the depth.
*Oxygen Not Included has a similar priority system, but that game runs so differently to Stonehearth I’m not sure how applicable its lessons are, save one: a lot of rookie ONI players will set everything to priority 9 (max) and wonder why nothing gets done faster 
Dwarf Fortress of course is the grand-daddy of this sort of priority system, but that’s a whole other level of complexity and IMO Towns is a closer match… although I wouldn’t personally be against going full DF, I don’t think it would be worth the effort and I reckon that a much more simple/elegant solution is possible.
