Is this wrong use of JMS could be responsable for his CPU hog?

You don't provide enough information to say.

My guess is that since you're invoking createQueue every time you send a message that you're also creating a new connection, session, and producer as well which is a significant anti-pattern.  Connections specifically are heavy and meant to be re-used whenever possible.

In any event, to track down the cause of CPU spikes you'd need to gather thread dumps from the server at the time of the spike to see what's really going on.

But now I'm curious to know the implications of this wrong approach.

How Wildfly handle this queues? Are these queues "physical" like the JNDI ones?

As the JavaDoc for Session.createQueue (which you linked) states, "Note that this method simply creates an object that encapsulates the name of a queue. It does not create the physical queue in the JMS provider."  The Artemis client will also perform a query so that if the name of the queue which is passed to createQueue does not physically exist on the server a JMSException will be thrown.  This query is probably less costly than performing a JNDI lookup because a JNDI lookup needs its own connection (which you're probably creating every time you do a look-up).