While I do think Monoid is something we should support eventually I don't have opposition to this more ad-hoc solution in principle. I can see how providing a default instead via ?? instead of having to provide a correct initial value could help some people avoid mistakes.
However, I see that you have changed the name to reduce. There are currently two overloads of reduce in the standard library and you are proposing adding two more. I am not as averse to overloads as some people are so I'm not opposed to this in principle either. But I think it's pretty clear based on past comments by the core team and standard library team that the size of overload sets in the standard library is not going to be too large so there is limited space for overloads of reduce.
If we're going to add another overload, my top priority would be the one taking an inout initial value that @stephencelis posted about earlier today. IMO, this is the most fundamental reduce primitive. All other variants can be written efficiently in terms of it while it cannot be written efficiently in terms of any of the others. If the argument against that overload (that "reassigning" uses of the existing into overload could be optimized to be equivalent) has turned out to not be true in practice then perhaps that overload should be revisited.
So I'm not opposed to this in principle but I don't want to see this proposal get in the way of possibility of accepting (in the future) APIs that I feel are more important. I'm not sure where that leaves me on your current design, but my impression is that 5 overloads of reduce is definitely more than will be accepted for the standard library.