Takticki atraktivan naziv, asocira na Doctrine, privuci ce dosta poseta :)
Iskreno, na CMS-u koji koristimo zadnjih nekoliko godina jos uvek se koristi global $config[], i to jednostavno RADI as expected, i malo je nezgodno refaktorisati sad to, jer prvo nema realne potrebe, settings se skuplja iz config fajla i spaja sa setting tabelom u bazi tako da je fleksibilan i lako se radi sa njim.

Ovako teoretski, radije bi koristio nesto sto pouzdano radi a koristi se (pise se) sto je krace moguce, cisto iz prakticnih razloga jer "stedi prste" i ne zamara sad prevelikim razmisljanjem pogotovo sto je u konkretnom slucaju to config, treba mi da ima get, set i save (mozda save), i da pouzdano svuda radi ako vec ne treba da bude global $niz.
E sad, verovatno nisam kompetentan posto 8h dnevno koristim global $config, ali mi je ok pristup koji sam video iz codeIgnitera, gde se prilikom ucitavanja frameworka u kontroleru (ili kako se vec zove) setuje $this->config i odatle se svuda izvlace settingsi, kako god se taj pristup teoretski naziva. Ako je potrebno config iz metoda modela, onda se samo pokupi instanca codeIgnitera i pici se regularno dalje. To mi je ok jer se samo jednom vade settingsi iz baze/fajla/odaklevec. Ako factory funkcija to isto uradi samo jednom, onda ne vidim nikakav problem sa tim.
a mozda sam i promasio temu

Ima li još neko mišljenje o svrsishodnosti functionless stila ?

Postoji li konkretan razlog da ipak pišem Settings::getInstance->...

postoje situacije kad je to ok. Ali ne treba preterivati..

Ako je jedini razlog da izbegneš sukob u imenu, koristi prostore imena: http://www.php.net/manual/en/language.namespaces.rationale.php