Lze se spolehnout na destruktor?

Vyjmenovat případy, kdy se konstruktor nezavolá, je dost složité, protože je manuál neuvádí.
Obecně lze říct, že destruktor bude zavolán ve chvíli, kdy na daný objekt již neexistují reference, nebo při ukončování scriptu v libovolném pořadí. Tady je velmi důležitá poznámka o libovolném pořadí, která prakticky znamená, že se nelze spolehnout na existenci jiných instancí (když jsem si tohle kdysi dávno přečetl v Mistrovství v PHP 5, tak jsem osobně na destruktory v PHP mírně zanevřel).

V důsledku bych řekl, že použití destruktoru je v pořádku, pokud si vystačí s nativními funkcemi PHP. Smazat soubor nebo ukončit socketové spojení bude myslím v pořádku. Uklízecích a logovacích operací bez závislostí bych se nebál.
Ukládání důležitých dat bych mu ale osobně nesvěřoval (tím spíš, že pro přístup do db používám uživatelské mezivrstvy). V destruktoru se blbě ošetřují chyby, pokud něco selže, je to problém. Vyhození exception v destruktoru vede na fatal error. Návrhově mi to také úplně šťastné nepřijde; po skončení vykonávání Modelu bych měl mít imho jistotu, že je aplikace konzistentní a tento stav reflektovat při vykreslování View, kde o tom informuji uživatele.

Další případy, kdy budou problémy, jsem našel v stackoverflow.com/a/3434279 nebo stackoverflow.com/a/2385581. Např. při vypršení časového limitu se destruktor nezavolá.

Nestrkej do destruktoru aplikační workflow a už vůbec ne práci s jinou třídou, jak zmiňuje Alphard. Pracovat s databází také není možné, je velká šance, že již spojení na db nemáš k dispozici.

Jediná věc, která se v něm dá dělat je uklizení, smazání dočasného souboru. Počítej ale s tím, že se tak občas nestane. Co vím, nezavolá se při out of memory, fatal errroru, killu aplikace atd.

Já používal destruktor na jednu jedinou věc, měřil jsem si takhle dobu běhu skriptu na serveru než to začaly dělat frameworky za mě.