You are right, it needs to say "Legacy Address", I've edited it now.

It is a big pity we still have exchanges using such outdated address types

real data wise there is not much difference between legacy vs segwit..
the reason transactions are TREATED as cheaper, is a form of miscounting actual bytes.. basically a false economy to entice people to use a new thing even if the benefits are tweaked/misrepresented

also back in legacy days pre segwit transactions were averaging 2000tx and had potential of 4200tx a block.. now fast forward.. we have segwit allowing all this crap meme bloat junk thats not validated. not lean, and not helping increase the tx count.. we are not averaging 8k-16k tx, not even close

id rather use keys where the system does actually count every byte and validate every byte.. you know good code

once you realise certain opcodes can be used by wallets to have multiple paths of signing, where even you wont know what type of signature is needed to spend later.. your funds can be at risk unless you are checking every transaction you make or receive at the raw data level, your you manually created the public address  so if you are unsure, just go with the battle tested key formats that just do the job as promised.. (and thats why exchanges with many employee's involved stick with legacy)

just remember, core devs MADE legacy more expensive via bad code in the fee estimate math.. and they can do the same with segwit
if we just asked devs to put their politics aside and wrote neat clean code that actually counts bytes, everyone can pay equally
legacy is not expensive due to a flaw. segwit is only discounted because devs decided to discount segwit.. but that discount can end with a few lines of code

instead of trying to get people to shift to segwit. we should be demanding core devs get off their high horse government status of control. and instead make some clean code that actually counts all bytes, validates all bytes and not be so cludgy and patchy. then we can all enjoy a better more appropriate system, insted of this game they are playing.
imagine an actual 4mb block thats actually counting bytes and allowing actual legacy transactions to use the entire 4mb space. it means more transactions per block and less dead data thats disregarded, less not counted data, less not validated data..
..you know good security

You mean the transaction? The issue with legacy address was the transaction malleability in which the txid of a transaction can be altered but the transaction itself is not reversed.

What that can lead to transaction to he reversed is chain reorg and 51% attack but which can affect any address type. Chain reorg may be of no issue because the transactions that was added to the stale block will likely be contained in the block that has the longest chain. And transactions that are not there will likely be later confirmed later in another block. But the problem is that the transaction may have low fee and if the mempool become congested like immediately and for long, the transaction may later be dropped from the mempool in a way the sender can double spend it. This is not about the address someone is using.

Segwit, mostly native segwit offers a better compatibility across exchanges. Most exchanges have adopted it because of its speed and lower transaction costs. I was disappointed to see that Bitget still uses legacy address as its only supported address for bitcoin deposits. They are really backward with technology.

Taproot is the most recent innovation, although its usage is still growing, but its features are noteworthy:
- Introduced in late 2021 as part of a major upgrade to enhance privacy and scalability.
- Supports complex multi-signature transactions that appear as ordinary transactions, improving privacy.
- Uses the Bech32m encoding scheme for better efficiency.

https://crypto-corner.com/2024/09/30/legacy-native-segwit-nested-segwit-taproot-bitcoin-wallet-addresses-explained/#:~:text=The%20primary%20Bitcoin%20address%20formats%20are%3A%20Legacy%2C%20Nested,protocol%20%28a.k.a.%20forks%29%20that%20have%20occurred%20over%20time.

Earlier, maybe a year or so ago, Binance supported Taproot, but I cannot see it in the networks recently, maybe they suspended support for it. I don't know if anyone noticed too

While the elevated transaction fees are undoubtedly the key point that makes P2PKH addresses less appealing in use, there’s another often overlooked issue i.e. they are case sensitive, meaning that even a small change in address ^{for instance the use of the lower case for single character instead of the upper case or vice versa} results in a completely different address. Thus, using them users are more likely to make fatal mistakes especially at their listening comprehension.

Who knows... it's never 100% guaranteed. Some of these addresses might be valid meaning that if you send funds to them the client validates the relevant checksum and they're likely gone for good from sending wallet. The sender loses the money and the receiver ^{whoever controls that address} gets the surprise ^{in the form of bitcoins} "out of nowhere".BTW, these kinds of "surprise" may happen due to simple typos when someone manually enters the wallet address.

I'm aware of the math behind addresses. However, it still doesn’t equal zero. Also, transactions might be sent to incorrect address through clients or online services that ^{for whatever reason} don’t perform checksum validation. It’s always better to be safe than sorry an avoid the potential mistakes done on receiver's address that could cost you money. ^{Thanks for this opportunity to answer you} .


Regarding "very small number, practically can be neglected", the odds of you being born were even smaller, yet here you are, typing on this forum.

Be dismissive of the small numbers is the pretty bad practice.