A PIN is really a numeric password. It has all the same flaws - compromise risk (say via social engineering) and the risk of forgetting and needing it reset.
So the ‘passwordless’ option here is either rename the password to PIN or eliminate it to provide single-factor login. The latter is a dream for smart attackers, since there is always some social engineering route they can use to acquire a legit token.
You would have been right if not for the important keyword "on-device". The PIN does not risk being exposed by server breaches, because it's never on the server. Yes, it can be extracted via clever con artistry, but that's true for _any_ "something you know" factor including conventional passwords. The whole point of multiple factors is that they have _different_ sets of weaknesses.
Also: unlike a shared secret like a password you share _everywhere_ (and let's face it, most people do), an on-device PIN can be changed in a single place should it ever be compromised.
Not all the same flaws; malware will have a much harder time recovering it. Also, you can use a regular password to "semi-authenticate" with the call center of the service and try to get them to disable the second factor, but this PIN is only useful with physical access to the device.
The key feature of security tokens is that it’s very difficult to extract or manipulate their internal state. A short numeric PIN enforced by a token is much more secure than a high-quality password whose hash is stored in a database: the token can rate limit PIN attempts and zeroize itself if too many attempts are made.
So the ‘passwordless’ option here is either rename the password to PIN or eliminate it to provide single-factor login. The latter is a dream for smart attackers, since there is always some social engineering route they can use to acquire a legit token.