I believe the "end of your script" part is the problem. Imagine you have some
object (say, ActiveRecord style) that writes itself to the database when it's
destroyed if the data has been modified. Now cache that object in a static
variable somewhere for performance. You're also using PDO, so your database
connection is a global or singleton instance of the PDO class.
Then your script reaches the end. Does your object get destroyed and
therefore saved to the database before or after the PDO object goes away? I
don't actually know.
I'm not saying that manual destructor order is the correct way to deal with
that issue necessarily, but I think that's the sort of use case it's intended
to address.
If you want to treat a PHP script as a traditional application, you should be prepared to unset() and keep references of everything yourself. Relying on the garbage collector for your business logic to work is just bad design.
I'd personally always explicitly do a ->saveObject in similar situations as its predictable and quite frankly never found a use for a destructor other than debugging..
Sounds like a subject that doesn't belong on PHP-DEV in any event.
Evert