This question has not asked before as the premise is different.
The Client secret is for the authorization server to verify a user is using the ACTUAL client to log into the system; Not a rogue client created by a hacker.
However, a rogue client does not need to authenticate with the server. If a user supplies his username/password on a rogue client, the hacker has literally stolen the password. He can then come to the ACTUAL client and login with the credentials.
I know we can employ two factor authentication to prevent this. However, my question is: why go through all the mess of having Client Verification as mentioned in the OAUTH Authorization/PKCE flow if it doesn't really matter for the password stealer?
https://auth0.com/docs/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce
Finally, the hacker can employ web scraping strategies to automate data capture from the actual client.
The client secret simply isn't there to prevent unauthorized persons from logging in, so don't get hung up on that threat. In OAuth flows that use it, the client secret is there for non-repudiation, for the benefit of the resource server. With client secrets in place, the resource server can know exactly what client ( == application server) requested any given token. That way, if the client fails to properly protect its tokens & proxy its users' requests, to ensure abusive or irresponsible sorts of end-user traffic never reach the resource server, then the client can be identified with certainty and its authorization can be revoked. Or it can be temporary rate-limited if it has exceeded the SLA, etc. Problem solved -- for the resource server!