Yes, this is exactly what sprung to mind when I read this proposal. In my opinion, the biggest disadvantage - just as in Monero - is the need for transaction scanning.
There were around 100 million Bitcoin transactions in 2021 [1], while Monero only had around 5 million transactions in the same time [2] - a factor of 20 that is not insignificant I'd say, especially when using an SPV wallet. If you open it after a few weeks or months of inactivity, it will have to churn through a ton of computation if such a scheme was introduced in Bitcoin.
That's easy to prevent: don't add Silent payments to SPV wallets. If you want to use this, run your own full node, and keep it online. You'll download everything anyway, and only have to check a few transactions per second. That shouldn't give any problems. And it's better for privacy.
What if you have billions of page loads? For a site such as TPB, that's very well possible and it means they have to monitor billions of addresses. Even if you don't monitor them continuously, you'll have to regularly check for donations. I haven't seen any website that shows a new Bitcoin address on each reload, which confirms to me it's not feasible.
With Silent payments, you only have to monitor a few transactions per second.
That's a good point. Especially since you need to run a full node anyway when using a current implementation of what's described here (such as BTCPay Server). In this case, it's required to scan all derivation paths - up until the 'last generated address' - forever, since someone could get a new generated address from your site, save it and donate money to it a few months or years later. It can be 'attacked' by making the software generate thousands or millions of addresses, so you'll need to continuously scan for
m/84'/0'/0'/0/1 to
m/84'/0'/0'/0/918231812 from that point on, for example.
Though that's exactly what you're doing with silent payments as well, right. Check a few transactions per second (a few thousand per 10-minute interval) and match against all possible derivation paths based on your seed / public key, pretty much.
But what if I send a very specific amount. Then I could just look at the next block, find that amount and see to which address it is send in reality. So at least the sender can very easily verify the real address.
Besides the sender knowing the real address, since that's where they send their money; in Monero, the sent amount is encrypted and you can only observe from the outside that input and output amounts match. I'm not sure if the silent payments proposal includes something like this, but I'm pretty sure it doesn't.
All in all, it seems to me like this silent payment proposal is basically just going to move this 'feature' from application level (BTCPay) down directly into the protocol level. Since it doesn't change the requirements or effects compared to the current application level implementations (full node, always on, scanning basically just as much), I currently don't really see the need of it. Without need of blockchain scanning, it would be a nice addition for people who want to receive donations and don't (want to / can) run a node.
Generally, I believe it's universally accepted that keeping the 'base layer' compact and simple is better, unless it's absolutely needed. For instance, SegWit allowed to build Lightning and had many more new advantages, but it was a relatively compact change and it didn't change more than what was absolutely needed. Or also Taproot, which allows to do new things that weren't possible before (opposed to moving existing functionality to the base layer).