From my reading of the articles (and my own testing), the issue at hand is that many default SSH daemon configurations for IoT devices leave TCP forwarding enabled by default (AllowTcpForwarding). This basically means "open proxy for people that can authenticate".
Once a user authenticates (be it via password or public keys), even if they don't have a valid shell defined for their account, they can still do port forwarding. Since many IoT devices are going to be using default username/password combinations, if someone can access the SSH daemon on that device, they can use it has a proxy. If they don't have the credentials or the public key (when using key based authentication), they can't do anything, even if AllowTcpForwarding is enabled.
Moral of the story: don't allow unprotected SSH to an IoT device (or really any device) and make sure it's not using default or common credentials for access. Also, if you don't need it, turn AllowTcpForwarding off.