Security consequences of HMAC(m, K) instead of the correct way HMAC(K, m)
$\DeclareMathOperator{\HMAC}{HMAC}\newcommand{\ipad}{\mathrm{ipad}}\newcommand{\opad}{\mathrm{opad}}\newcommand{\xor}{\oplus}\newcommand{\concat}{\mathop{\Vert}}$Yes.  It becomes vulnerable to collisions in $H$, if $m$ is longer than the block size of $H$, because in that case $\HMAC_m(k)$ is not actually $$H\bigl((\opad\xor m)\concat H((\ipad\xor m)\concat k)\bigr).$$  Rather, it is $$H\bigl((\opad\xor H(m))\concat H((\ipad\xor H(m))\concat k)\bigr).$$  (See RFC 2104, §2 ‘Definition of HMAC’, p. 3.)

What about single-block messages?  Well, it's unlikely that an attacker could find a structured pair of collisions $(\ipad\xor m_0, \ipad\xor m_1)$ and $(\opad\xor m_0, \opad\xor m_1)$ in $H$ for $m_0 \ne m_1$, but if they could, and if $H$ is Merkle–Damgård as is assumed in the usual HMAC security reductions (and if it's in the BLAKE2 or SHA-3 family, why bother with HMAC?), then $(m_0, m_1)$ would collide under $m \mapsto \HMAC_m(k)$ for any key $k$, enabling an attacker to immediately distinguish it from a random function or to forge messages authenticated under it.