How much of a role should "enthusiasm" play in the software development process?

Its complicated.

I cant comment on the prioritization by user needs, business value etc. Cause I'm not product. But as a engineering manager I can say happy engineers become less happy if they do not feel "heard". If you want your team stable and consistently bringing product value its best to mix in wins for product to build up good karma with their engineers.

Maybe you read this and you say no product/business value only. We pay these people to write software you dont get to influence this. I would respond that people are complicated and coding is often a creative endeavor. Nothing kills creativity like being burnt out, upset, or tired.

No but it leads to developers to say good bye to you for greener pastures where they are enthusiastic on working on it.

It doesn't really come into play for me. Its pretty hard to justify to a customer that we're going to work on X first because "that's what the devs want". I think the item in question should be justified based on its own merit, not as a "we're just trying to make developers happy".

I think the issue is a lot of developers don't spend enough time trying to understand the business side. Because of this they fail to articulate the value a certain item may bring to the company.

False dichotomy. Developers should be enthusiastic about solving a problem using the appropriate tools, with an eye to beauty in the code (as the opposite of complexity), and efficiency in how they work. They should have near carte blanche over how they're going to solve the problem, but not over what the problem is.

(Unless they manage to convince three business that the problem is actually elsewhere... that's legitimate).

But the idea of choosing the next bit of work based on Brad's burning desire to write some React or whatever? Smh, tell Brad to grow up and if he quits I'd breathe a sigh of relief. This infantilising of developers has got to stop.

I don't think that there is a fixed rule for this, but managers should allow their developers from time to time to freely try new stuff or technologies that they like to work on as soon as they don't affect clients' urgent deadlines, and this could also be another way for the company to keep track with the new solutions and techniques.
This way the developer will remain enthusiastic and his\her productivity might increase as well.
On the other hand developers should also try to satisfy their passion in software by themselves on the side and away from work, work's tasks are not always exciting and some might be boring and this is normal.

An enthusiastic person would be someone that is easy to work with, is excited about a lot of things, jumps at opportunities, etc. Not someone willing to work after hours without the need to do so, learn new tech just for the job without being paid, etc. more or less someone who enjoys doing their work but doesn't live and breathe it.

Enthusiasm is something that is commonly found among older developers, while you find passion in newer developers.

Like you said, prioritization is complicated. There is no one way to define it.

As for enthusiasm, this is the key that would spur the developer to learn and pick up more value for the business. Without enthusiasm, the developer would stagnate and stop growing thus not being able to provide newer/better solutions to a problem.

Looking further, a developer enthusiasm could also be driven by many factors. Overall, humans are just complicated creatures with many environmental factors that could come into play.

I used to think this was more important than I do now. What changed was working with diverse teams with different personalities many of whom brought every bit as much to the product as the enthusiastic folk. (I will own up to being one of those enthusiasts)

Interesting question. I don't have a short answer, only some observations.

Overall, I guess I'm in the camp of having user needs & business value be the guideposts for prioritization. I think I'd define business value more inclusively than many; paying down tech debt, for example, often provides business value by my standards. That said, my bar for some stereotypical enthusiasm projects ("let's rewrite our stable customer-facing backend in golang!!!11") is pretty high. They're fun to do for an engineer, and maybe address some benign but offensive code smells, but hard to justify the opportunity cost if they take time away from work that produces more direct value, especially if what they're fixing is "good enough" overall.

I think as we get more senior as engineers, we tend to do a better job of connecting things that we're enthusiastic about for our own reasons to business value/user needs/etc. For example, helping to justify a refactor or code cleanup by understanding the product roadmap, or identifying a business/user-facing gap that can be addressed with a new technology or product. Enthusiasm all by itself may not be given much of a role here, but arguably it doesn't need one; the business value it produces speaks for itself. Of course, this requires a rapport between engineering and the business that may be rare in practice.

As others have mentioned, enthusiastic engineers who feel like their enthusiasm is discouraged or shut down may leave for greener pastures. 20% time, internal tools that can tolerate some amount of churn/instability more readily than other projects, etc can all help provide outlets if they're not to be found in day-to-day work.

If "enthusiasm" means "let's try the newest JS framework or this new DB" this must be heared and answered, but can not be a prio descision maker. BUT it must be answered in a good way via eg discipline meetings.

Now... What for sure must be taken very seriously is "enthusiasm" regarding solving Tech Debts. Not every Tech Debt is high prio, but if it's one which has high cost because of using expensive resources, do disturb much people (affecting overall productivity) it should get attention regarding prio definitions.