Allora, prendiamo in esame questa caratteristica e forniamo uno spunto per chi volesse ragionare (in assenso o dissenso, è immateriale: va tutto bene): defineProperty.

Il significato di questa sintassi è: assegnare ad un oggetto, ad esempio
var foo={}
le sue proprietà.

Un tempo facevi (ad esempio)
var foo{'ciao':'hallo'}
oppure
var foo{}
foo.ciao='hallo'
oppure
var foo=[]
foo['ciao']='hallo'.

Tutta internet va avanti, con siti dello spessore di Amazon e quant' altro, usando queste sintassi.

Cosa introduce invece definire la proprietà con Object.defineProperty ?
Questo: che puoi settare se:
è writable: se puoi riassegnarli un valore
è enumerable: se passando ad un loop l'oggetto, la proprietà ti apparirà come esistente o meno (uh, che caratteristica interessantissima...! ci perdevamo il sonno ad attenderla)
è configurable: se puoi, ad esempio, cancellarla.

Ora, cosa c'è dietro questo approccio? Fondamentalmente, il nulla. Mozilla e le specifiche cioè (verso le quali sono critico da anni e anni poichè è invalso il costume di seguirle con venerazione acritica, anche quando sbagliano - oh sì, anche loro sbagliano - e inducono ad applicarle perchè fa moda - quel che da anni io chiamo "Codice Armani" - e non perchè serve o se ne è compresa la utilità) stanno perseguendo una agenda nascosta che non è dichiarata, ma che è ovvia.

Essa è composta da due obbiettivi.

Il primo, a mio avviso pericolosissimo: quello di incoraggiare la programmazione per ambienti dove il programmatore non ha alcun reale controllo - infatti se io ho il controllo di un ambiente, non mi serve settare una proprietà a non scrivibile: se i miei codici sono robusti, e ne ho come dovrei il pieno controllo, i miei codici non scriveranno dove non devono.
Queste sintassi mi incoraggiano, subdolamente, a perdere il controllo confidando nel fatto che un pezzo di codice compenserà alla carenza o negligenza umana.

Il secondo: javascript, linguaggio non fortemente tipizzato e nato senza le caratteristiche davvero object oriented di java, si sente figlio di un dio minore, e cerca disperatamente di ovviare alla sua identità percepita come vergognosa, tentando di divenire quel che non potrà mai essere: un linguaggio di alto livello - cosa che appunto non potrà mai essere, perchè opera sul lato client e non potrai mai chiedere ad un client (e a tutta la galassia di marche e versioni e sottoversioni dei browsers diversi e di utenti occasionali che hanno l'autoupdate off per motivi che chissà quali...) di operare con i processori che permettano la gestione delle librerie di un C o di un Java - guardate in questo contesto il grande futuro che hanno avuto dietro le spalle le applet java, e il ridicolo di cui si copersero con il loro motto (che forse alcuni ricorderanno) "write once, run everywhere" - spesso trasformato in "write once, debug everywhere".

Vale la pena aggiungere, nel contesto di questa seconda osservazione, che il motivo per cui linguaggi come Java o C sono fortemente tipizzati non è nè è mai stato quello di permettere al programmatore di non effettuare operazioni che il programmatore stesso ha voluto illecite sollevandolo dalla incombenza di scrivere codici controllati (per quanto un simile intento sia condonabile o comprensibile in codici che producono OS o GUI complesse come che so OpenOffice - ma javascript non produrrà mai cotanto codice da affidare ad un client), ma quello di garantire la velocità del processore il quale sa che tipo di dati, ad esempio, gli verranno affidati poichè gli vengono preannunziati.
Ma della potenzialità esibita da un processore su un browser client, garantisce Pantalone e non javascript.

Non è che dico che uno non debba usare defineProperty.
Dico che uno dovrebbe usarla solo se le esigenze ad esempio di non rendere una proprietà visibile alla enumerazione si fanno cogenti e fondamentali per la vostra applicazione.
Non accadrà spesso, Johnny.

In effetti, fino ad oggi non ti era mai accaduto e semmai fosse accaduto, sapevi come domare il tuo codice.
Perchè queste procedure presentano anche un rischio: impediscono al programmatore di rendersi conto di manovre illecite performate dal client. Un utente ad esempio dalla location bar riesce a fare una injection per alterare un mio ajax: siccome la proprietà della mia classe ajax che cercava di manipolare è settata a non writable, io non me ne accorgo, e... continuo a dialogare con questo client.

Ma di pericoli ne abbiamo già abbastanza con i client, senza che nuove specifiche ci inducano a risolverli chiudendo gli occhi.