normalized_factors function and the helper function factorizable are needed only to increase effectiveness of sequence generation and caching by reducing non-optimal sets of factors to the optimal ones that provide the same resulting sequences.
E.g. factors (2, 3, 5) and (3, 15, 2, 4, 16, 5) make exactly the same sequence (Hamming numbers) so it makes sense to reduce the latter to the former before doing actual computation. And that's what normalized_factors function do.

It took me some time just to understand what's going on in your solution. Don't have an idea how did you come to it in the first place :-(

Once I got it, though, I immediately thought that it's the best one!

First, it's fast (of course, everything could be optimized a little bit more :-)).

Second, this presentation makes it very easy to generalize.

Thanks!

This is a generalized solution for any arbitrarily selected factors.
With blackjack and caching!
With caching disabled it's just a little bit slower than the optimal solution for Hamming Numbers (15% or so). With caching enabled it's, of course, orders of magnitude faster on a relatively large sample of numbers than any non-cached solution.

Modification of eugene-bulkin's solution. No external dependencies.

Very simple and clean. I think this is by far the best one.

A slight modification of xcthulhu's marvellous solution.

By far the best solution in terms of both clarity and performance (in my tests it's almost 10 times faster than the solution with list comprehension).

This is clever indeed, but why is it marked as a best practice?

For the list of length=400, in my test environment it's four orders of magnitude (6000 times to be precise) slower than, say, Kjwon15's solution (which is only marginally slower than the direct solution using dict).