When creating a many to many relation with an attribute, should I include a non-composite primary key?
What are voltage and efficiency?  Simple numbers (SMALLINT) or FLOATs?  Then do not normalize them and do not use a many:many table.  Simply have the value in the table instead of an id pointing to the value.  There is such a thing as "over-normalization"; it does not scale well.

Use many:many mapping tables for relating things that have lots of attributes.

Back to your question...  A many:many table does not need a surrogate id for the PK.  It is not just OK to have a composite PK, it is actually more efficient to have such.  Save AUTO_INCREMENT for cases where there is no good "natural PK".

Other tips on many:many tables.  Note that it advises having a secondary key for when you need to 'go the other direction'.

(Based on Comment):

Using ENUMs:

voltage ENUM('unknown', "460/60/3", ...)  NOT NULL
efficiency ENUM('unknown', "ie1", ...)  NOT NULL


Using a string:

voltage VARCHAR(15)   CHARACTER SET ascii NOT NULL DEFAULT ''
efficiency VARCHAR(8) CHARACTER SET ascii NOT NULL DEFAULT ''


Normalizing:

voltage_id TINYINT UNSIGNED NOT NULL ... and another table
efficiency_id ...


If there are very few choices, and the list of choices changes only very rarely, ENUM may be optimal.  The 'string' option is not too bad since the strings are rather short.  I feel that the normalizing is "over-normalizing" in this case, namely only a few short strings.