Il principio di responsabilità unica promuove la flessibilità?

Sì. Una classe che fa una cosa può essere riutilizzata in altri contesti facilmente dove è necessaria tale responsabilità; se una classe ha più di una responsabilità, nella maggior parte dei casi quelle altre responsabilità creano dipendenze che potrebbero essere difficili da soddisfare in un contesto diverso.

Esempio: una classe che esegue alcuni calcoli è facile da riutilizzare. Una classe che esegue il calcolo e memorizza il risultato nel database è difficile da riutilizzare in un contesto senza un database, anche se è necessaria solo la parte di calcolo. Forse il costruttore richiede un oggetto di connessione al database, forse il calcolo esegue implicitamente l'aggiornamento.

È un modo interessante per definire la flessibilità. Ma c'è molta verità in esso, cioè se una classe è robusta (come la chiamerei io), sei flessibile nell'utilizzarla.

Il principio di responsabilità unica non "promuove" in modo esplicito la solidità. Si dice solo che una determinata classe dovrebbe essere progettata per un singolo compito. Entro limiti più ristretti, la robustezza è molto più facile da ottenere (come un'anologia: un coltellino svizzero è meno robusto che un Opinel ).
Più il compito è ristretto, meno ipotesi implicite meno necessarie che potrebbero infrangere la classe quando non sono valide, perché il codice client non aveva idea di essere lì.

Tuttavia, l'SRP si concentra sulle qualità interiori di una classe. Ciò che ti interessa è il comportamento esteriore. Tale comportamento dovrebbe essere astratto in base al DIP e decomposto in base all'ISP. Da qui deriva la flessibilità: è possibile collegare le implementazioni a proprio piacimento e le implementazioni sono facili da realizzare (non è necessario implementare 50 metodi).