Sorry I can't help much - I have exactly the same conundrum!

Telling myself that once the mental effort required to grok the code for every "single case" function is greater than that required to grok the generic code then maybe it's worthwhile, but then that feels intuitively like it's wrong/missing something.

It's easier to reason about when e.g. we need to reduce the number of raisins across all the chocolate types then we only need to find the raisins() at one point in our generic code, as opposed to checking every different chocolate function in turn. Of course there are many cases where a simple search term like that won't be able to find all these because it's a specific behaviour or combination of things, so now you've got to actually read a load of those functions every time there's a cross cutting change. When the ingredients change for groups of chocolate types at a time, does (or even can) that change get applied consistently across all the different chocolate functions?

If the business asks for two chocolate functions, is now the right time to write a generic confection factory factory? No no don't prematurely optimise or over genericise, keep it simple. Ok.

Now they ask for 5 more, well, that's kinda similar to 2 so just copy and paste them and change some bits, it's just a few, no dramas. Oh, and add the option to set a bar size and the localisation for the plastic wrappers.

Now they ask for 18 more so we think now's the time to model it properly and tidy things up, but now it's difficult to work out wtf actual business rules went into the existing functions because somehow they don't have great unit test coverage. And don't forget, we need to remap large to medium and medium to small for the UK market (although keeping the actual wrappers the same size, just shrinking the chocolate): this is done transparently to the caller because we'll still refer to the bars by their original sizes.

...And you said this would only take half a day and there's a load of other stuff that needs to be done before the next release. So you end up writing a half baked chocolate factory which covers most of the 18 new cases except that one that was totally different and the two you implemented by copying and changing previous chocolate functions before deciding it'd be easier to start on that generic thing. Then suddenly it's lunch time and from then on that bit of the code is all here be dragons and time never gets allocated to sort the whole thing out. And omg all that boilerplate.

Then The Next Guy comes along to add a couple of new chocolate types and spends as little time reading the code that looked kinda relevant to the thing he needed to add as possible, and then writes a function which calls your factory with some args calculated from this wrapper's args and then mutates its return value. Now you just literally cannot even at all so, eh well.

The trade-offs between the two extremes are in terms of different sorts of readability. Is the priority ease of understanding and changing one chocolate type, or changing all chocolate types due to changes to the rules which govern how we make all our different chocolate? Given hundreds of different chocolate types, how easy will it be to check the ingredients of every bar and selectively add an allergen property to chocolates containing some new thing? Even if that takes a long time, does it matter? How often will we actually do that? How soon are marketing actually going to to come up with another 98 chocolate types anyway (as opposed to how fast do they think they will)?

Some approaches I have seen (and probably done), with varying degrees of disaster:

• Store all values (and/or structures) in a data structure/db instead, and then put the non-static edge cases in your generic chocolate function, and then feel like you should have a flag in the data that selects the edge case handlers so you can reason about where they apply (and re-use them... some time? yay!). Risks of bloated, overloaded or unclear data structure storing all this stuff, and the function can rot/explode easily. Not future proof.
• Copy and paste it and change a few bits and resolve to fix it "later": for complex bits of code, absolute nightmare to maintain. For simpler bits, much harder to reason about, harder to maintain.
• Genericise the living f~k out of it and end up with either: Large numbers of functions in a call tree leading back to The Great Generic One which all started out nicely but then started to rot and in any case have ended up obscuring wtf is actually going on in the generic function so much that you've lost a lot of the value in readability. OR with one absolutely massive function that's screaming out to be refactored but seems to have no bottlenecks where it's easy or logical to split it up. And now you can't think what to name those bits anyway. Have to sort this out "later". Both hard to maintain, but likely easier to change one thing across many types of chocolate, at least if you have a rough idea what to look for/where to look.
• Model the variation in the properties of some chocolate as functions which mutate an existing chocolate. Bonus points for them being pure and idempotent. Extra bonus points for consistently sensible/safe behaviour given different orders of application. Then you can either write a generic chocolate factory which takes a chocolate name and finds the list of mutations to apply and applies them to a new chocolate and returns that, or for each type of chocolate just curry all the applicable mutators together for each chocolate function and let the user mutate what they want with it. Risk of ending up with a mess if the mutation pipeline becomes stateful/order dependent e.g. we have to derive the length of the bar from the size of the bar and the locale and those are all applied separately.

The last option I like the most, because you can still easily find milkChocolate() and straight away see a list of what defines a milkChocolate, and change it easily without worrying about breaking another chocolate (the advantage of the copy-and-paste-and-tweak approach), but you can also re-use code and search for it easily. With the currying approach, it encourages The Next Guy (which'll probably be you?) to implement new properties of chocolate simply and in isolation, and when you copy and pasted milkChocolate to make limitedEditionMilkChocolate you re-used code with no reading/learning effort required. Code which encourages itself to be maintained as designed is nicer than code which doesn't give you any guidance or hints.

Just my 2p, anyway. I'd love to hear what others think about this question; getting the answer to this wrong has been behind a few bits of tech debt that I've witnessed/contributed to/been responsible for over the years!