By that definition, most corporate backup systems aren't backups! It's pretty common to overwrite old tape backups with newer backups, and yes, that does mean you need to be organized enough to make sure you don't accidentally overwrite the only backup of something.
Maybe a better way to put it is that backups are isolated from current "production" data operations.
Backups are not invulnerable, so yes, it's still possible to overwrite the backups, but that involves engaging the backup system specifically. Just doing file operations or settings changes on the production system won't do it.
Dropbox is not isolated from production data operations. In fact the whole point is to synchronize production data operations as fast as possible. That makes it dangerous.
(This does not excuse the bug is this story; sync setting changes should be obviously be atomic transactions that are confirmed on the server.)
Not at all. Any backup system defines an RTO (Recovery Time Objective) and RPO (Recovery Point Objective).
Usually, backups are scoped to protect against system failure, so fast time to recover and limited historical durations are usually design goals. Being able to restore a server to it's state 20 weeks ago isn't very useful.
Dropbox is like shadow copies in Windows. You can go back in time, for the purposes of journaling changes to an existing object. It's a productivity enhancer for users, not really a backup feature.
Keeping things forever is usually referred to as backup. For example, my employer keeps certain records for 100 years due to statutory requirements. When you archive, you want to tightly scope what you archive and limit it as much as possible. Things like short time to restore are usually not primary design goals.
If I can delete parts of a backup, it's just as susceptible to the same human mistakes that make them necessary in the first place.