When Did a Small Requirement Change Cause Major System-Wide Effects?

Happens all the time. I like to call it "structural instability" [1]

I think an objective measure of software quality is that the situation you describe doesn't happen. As an experienced dev I've got a very good idea of what kind of things management don't think is small. If you have a discussion with management and decide to a cut corners relative to authentication, authorization, user onboarding, device compatibility, things core to the user experience, or managing inappropriate behavior it is very likely. that between one month and two years this will be revisited in a hurry.

(1) People are too sanguine about routine cases such as "adding a field to a form" requires: (a) creating a migration of the database schema, (b) editing a Model object on the back end, (c) editing a DAO object on the back end, (d) editing an API endpoint on the back end, (e) editing an analytics page on the back end, (f) adding a path to the API gateway, (g) editing a model object on the front end, (h) changing an JSX form on the front end, (i) adding a line of code that copies the form data to the model object, (j) changing the front end validation logic, (k) document all of the above and (l) probably fight with version control, the build system, dependencies and stuff.

Imagine another world where you make one edit to a schema and all the rest of it is code generated, 12 steps could get done to 1. (The elusive 10x productivity boost!)

This case isn't so bad because it's routine, if you are bothered by it you probably have a checklist that you can use yourself or hand to a junior dev. However, you should be consistently designing things with problems in (1) in mind, such as...

(2) Many times an application lets a user fill out N phone numbers or email addresses, say N=2. It's very likely management will decide this is not enough and mandate N=3, then N=4, ... Writing

   create table user (
     ...
     phone_number varchar(20),
     phone_number2 varchar(20),
     phone_number3 varchar(20),
     ...
   )

is for the birds, you are better off starting out with a data structure that lets you support 1-to-many relationship from the very beginning. For that you're better off making a user-facing user interface and an admin-facing UI from the very beginning where the user can click an "add" button to add another phone number field. It is on you to do the right thing as as soon as you can otherwise you're going to waste more effort N+1'ing it multiple times.

(3) The worst case is where a (1) situation interacts with bad decisions in (2) and the design and data structures are truly bad, the bad cases are far beyond routine, but the answer is that the type (1) cases should really hurt to you, you should be always be looking at type (2) solutions to head them off, you'll be making better decisions for the type (3).

[1] https://en.wikipedia.org/wiki/Structural_stability