Simple Ansewer: Use shift approach unless multiplicative constant is really big
In my experience, the multiply by constant followed by a shift will be more efficient than division in most cases.
The exceptions occur when the multiplicative constant is quite big and forces a more combersome multiplication to be performed, especially a multiword multiply.
Improvements to the handling of slope-bias casts in recent releases will make the occurance of big multiplicative constants less likely. Also, slope-bias scaling is most frequently used with types with 16 or fewer bits. Small wordlengths make it more likely that the multiplicative constant can be implemented quite efficiently.
More Details
As Walter noted, if you have a target that does not have an integer division instruction, such as an ARM Cortex-M0, then you want to avoid division. With no hardware instruction, division will need to be implemented by sequencing many other operations.
But division by a constant value is a special case. Even when a integer division hardware operation is available, it often takes many more clock cycles than other operations. Many compilers have lots of tricks to avoid using a division operation when the denominator is a constant.
Example with Godbolt Compiler Explorer
For gcc targeting Cortex-M4 (which does have an integer division operation) with these compiler options
-O2 -march=armv7e-m -mtune=cortex-m4
the division approach requires more code, but it doesn't actually use a division. The compiler exploited that the denominator was a constant and optimized it away. Instead of division, it used multiply and shifts. Sound familiar?
With gcc targeting Cortex-M0 with these options
-O2 -mtune=cortex-m0
the compiler has "optimized away" division by constant and multiplication by constant. Multiplication is still a little smaller. I did not count the clock cycles, but I'm guessing the approach that originated as a multiply-then-shift is faster than then the approach that originated as division-then-multiply.
