Naive: till scratch size is known at compile phase - is it possible to make unrolling loop for that determined size?
In case of compiler didn't make unroll it automatically...

It is not entirely clear yet. Could you explain in more detail?

Sure:

Scratch buffer size depends from MACRO definition here https://github.com/opencv/opencv/pull/21158/files#diff-fe0ac6b5a07c1bec59c3756100eb186c9117a82dd1d951ef6997b8423a89943dR1505

we have constant buffer size here for CV_SIMD turn on/off case... So it is possible to introduce MACRO branch here by CV_SIMD turn on/off and make manual loop unrolling in a way

#ifdef CV_SIMD
  cs[0] = _scalar[0];
   cs[1] = _scalar[1];
...<16  + 2 times>
#else

But from the other hand, C++ compiler can do this work of manual loop unrolling in more optimized way... But I do not known much details how is it applicable here: would C++ compiler make unrolling or wouldn't in this case - if scratch.length() has runtime (but not compile time) value.

So my point here: We can try to simply replace scratch.length() from dynamic parameter to constant parameter from MACRO where scratch buffer is determined and believe that C++ compiler would make loop unrolling or straight way vectorization here

P.S. this comment may be (or may not be ) applicable if this code is placed on critical performance path ONLY

It seems to me there are no sense to do this for current case, because this loop work just once when function is called for the first line of the handling picture. And the compiler usually does it well itself.

simple find on a page doesn't return to me anything about using this structure: where is it used?

Ok. Removed.

is it the same initialization which used for AddC? if yes - then maybe we need single common function to reuse in both?

Applied.

👍🏻
Now code for sum + sub is unified?

what do you think to rename op for something more less domain specific -> operation or op/operation_dispatcher ? too much short-named variables here and functions name stays hidden beside them

Applied.