Calling destroy in a has_many_and_belongs_to and has_many :through

I've noticed that if I use associations with has_many_and_belongs_to
and i call a destroy method on an object of the association, the
record in the join table is automatically deleted.
If I use has_many :though, for example:

Category
has_many :categorizations
has_many :products, :through => :categorizations

I have to put explicity

has_many :categorization, :dependent => :destroy

otherwise the association isn't deleted.
Why?

Msan Msan wrote in post #1061478:

I've noticed that if I use associations with has_many_and_belongs_to
and i call a destroy method on an object of the association, the
record in the join table is automatically deleted.
If I use has_many :though, for example:

Category
has_many :categorizations
has_many :products, :through => :categorizations

I have to put explicity

has_many :categorization, :dependent => :destroy

otherwise the association isn't deleted.
Why?

A HABTM B (to me) infers that the join table AB serves no purpose other
than to link As and Bs. Without a specific A, the AB record has no
meaning. So the HABTM specification lets Rails make the assumption that
when A is deleted, the AB related to that A can be deleted as well.

A has_many B
A has_many C, through B
implies (also to me) that joining through the intermediary table B is an
artifact of the relationships between As, Bs, and Cs, and the entity
modeled in B has value independent of its relationship between A and C.
Like

Project
has_many :scenarios
has_many :unittests, :through => :scenarios

When a Project is deleted, I don't want all those Scenarios deleted...

Unittest
has_many :testings, :dependent => :destroy
has_many :testresults, :through => :testings

When a unittest is deleted, I delete all the testings (and testresults)
since test results or testing instances aren't much use without the
requirements (the unittest).