The main difference between the solutions is in the way you want to discriminate different dataformats and where this responsibility has to reside. By relying on one-queue per format, you are binding the format to an infrastructure component. On the contrary, by using the Normalizer EIP you are discriminating the dataformats based on the message content at application level. The main drawback of the first solution is that it can't scale well and quickly, as you need to change both your infrastructure and application layers. It means also that a large number of formats requires an equally large number of queues (resource utilization and optimization may be an issue here).
I've tried to stick on the strict intention of the pattern itself and on the problem it tries to solve, also considering that more often than not translation does not require complex processing. Anyway, sometimes things are not that simple and you can choose to have dedicated queues also for better distributing the load, for example when one producer has huge volume or when translation logics and computations are not comparable among data formats. In other cases, especially when integrating your own multi-tenant application with other customers' systems, you can have routes strictly separated from each other in order to prevent bounded contexts from interfering one another.
That being said and to sum up it always depends :) As a rule of thumb, if you are the owner of middleware infrastructure and the number of formats is very small or is not supposed to change frequently or grow, probably both solutions are valid, even though I would always go with the second one if I don't need to scale based on workloads/customers and if the message content allows me.
Hope I helped.
