Why is Drop a trait?

Relatively experienced Rust developer here. My "question" is in the title. Also, see this more as a debate opportunity than an actual question.

It seems to me like despite being a trait, Drop has literally nothing to do with the inherent concept of trait. I don't have a specific list of what a "trait" should or shouldn't be, but here are a few observations of what differ from other traits:

• Drop doesn't describe something a type can do (unlike other traits): implementing Drop doesn't make a type droppable, all types can be dropped implicitly. It just adds code to the dropping process. Not overwrite, add; product types still call their field's destructors recursively.
• Related to the above point, you can't use Drop as a generic type bound since having a Drop implementation doesn't make a type special in any way.
• You can't call Drop::drop manually. Afaik — appart from Fn traits which are unstable — this is the only trait method that you can't call directly.
• Overall, the Drop trait describes implementation details that should be opaque, whereas normally, public traits are supposed to expose methods.
• The impl Drop syntax is a lot more restrictive than any other impl. For instance, you can't have impl<T: MyTrait> Drop for T. Again, that's a special case only for this specific trait.

It seems to me that Drop should've never been a trait in the first place when you realize how weird it is, and how much differently the compiler treats it. It would have been almost as simple and much more coherent to have a specific syntax to define destructors. Maybe even a simple attribute that refers to a function.

Obviously, it's too late to go back on this decision, but I'm curious to hear other people's thoughts on this.