Technically, it is just a different encoding. We don’t need the public key. All addresses can be converted. However, stacks only has two types singlesig and multisig. While bitcoin has legacy, segwit, etc . So we need to agree whichbbitcoin address type should be map to the single sig stacks address.
With stacking pool, we had the confusing that some pools used legacy, some used segwit.
Currently, it makes sense to use native segwit. However, bitcoin users with legacy addresses are left out.
With the mapping, we are loosing a portion of the verifiability of the transactions and smart contracts if we rely on tools that transcode addresses in transactions and contracts for us. Next step from transcoding would be compilers.
We are also creating some confusion about utxo models and account models. While my bitcoin address has been replaced by a change address on bitcoin, my bitcoin address on stacks is still the same. A solution could be to use smart wallets/account abstraction on stacks (some WIP here Add sponsored sbtc transfer by friedger · Pull Request #25 · friedger/Smart-Wallet · GitHub).
Users would need to learn what bc1234.. .amm-dao mean, what smart contracts on bitcoin L2 are.