Can SCR2 be float?

Yes, it can be. And next overload handles this case.

Is it supposed to have SRC1 & SRC2 for the same type (i mean if it falls into the div/mul with SFINAE with SRC1 & SRC2 then do we need to satisfy static_check(std::is_same<SRC1, SRC2>))?

This check is already exist. Please take a look here

looks like order is different with BINARY_
https://github.com/opencv/opencv/pull/21024/files#diff-fe0ac6b5a07c1bec59c3756100eb186c9117a82dd1d951ef6997b8423a89943dR787

What do you think to align: DST <-->SRC according to BINARY_ order or vise versa?

Two first arguments of div_simd() have SRC type. Third argument has DST type. So for MACRO I should mention SRC type first and second should be DST.

BYNARY_ macro is working good, so in the bounds of this task, I can't change API of this MACRO. Otherwise I have to change its invocation for all kernels that use it.

I see your point.
But what do you think to align argument positional agreement in newly added functions for mul/div in accommodation with the old approach with BINARY_?

UPDATED: Or it will affect template type auto-deduction?

IMHO: enable_if is good for simple condition check otherwise it confused
but as I noticed we need to pass type into v_load_f32 and others function, so we need to know actual type here...

IMHO again:
To avoid eyeballs scattering when reading this code i think it is possible to introduce MACRO at least

#define SRC_DST_SHORT_USHORT (std::is_same<SRC, >...)
#define DST_SHORT_USHORT (std::is_same ...)
...
template<...>
CV_ALWAYS_INLINE 
typename std::enable_if<SRC_DST_SHORT_USHORT, int >::type 
div_hal(...)
...
template<...>
CV_ALWAYS_INLINE 
typename std::enable_if<SRC_DST_SHORT_USHORT, int >::type 
mul_hal(...)

Feel free to ignore it

is there are no loop-unrolling MACRO in opencv?

Does it make sense here?