At work we're driving towards immutable components, that is: once a version of a thing (service, capability, API) has reached production it never changes. New versions are deployed to new endpoints (versioned ones :)), and consumers can choose when they start using them, paying customers included. This largely avoids the need for feature flags to 'hide' changes, makes roll-out and roll-back go away and decouples components as much as possible (there will be some version dependencies of course), giving component owner/delivery teams maximum autonomy - which seems to be the point of the original article.
This seems like a daft idea if you expect to ship lots of bugs, as you would be creating lots of endpoints and confusion, so a precursor here is to catch those bugs before production by having good contract tests in place (provided by all the component consumers). It also relies on good segmentation of components, so change is evenly distributed across them.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.