Some of the worst code I've seen in my life lives in Jupyter notebooks. But that's fine, it's meant to be throwaway code. The problem is a lot of places/people do not use it as such.
On the other hand, it accomplishes a goal other than getting a programmer paid. So in one important sense is objectively better than probably 80% of the code I've seen people paid to write, no matter how nicely it was constructed.
I spend a good deal of time covertly teaching software engineering best practices to folks who claim they don't want to be "software engineers", yet they are in front of Jupyter most days.
I'm a so called "scientific" programmer, and I use notebooks. I care about good programming practices, and have made an effort to improve my craftsmanship.
And I don't want to be a software engineer. I'm surrounded by SWE's in my work area, and their job doesn't really interest me. Division of labor. I'm glad somebody enjoys it.
That backend had decent integration tests, and it took less than 5 minutes to add a small new feature. Most prod code doing comparable things where I work is worse-tested, less reliable, and at least 10X more expensive in terms of SWE-time, so I think modern programming standards are actually nonsense even though I can play along with them.
Now when business requirements change and you're constantly sending people into that 1600 line backend function or whatever, it's likely worth it to start doing some refactors. But otherwise if I don't have a good reason to be in there I pretend I don't see it.
Could still be the best approach, if by "modify" you meant "added new queries to an array of strings".
I still have masses of admiration and respect for him, but no longer so much when it comes to software engineering - due to this, among other things. It seems like a great idea, but is clunky, hard to refactor and to integrate with other things, in my practice.
Wrapping production code in jupyter cruft doesn't work for me. Or, any code, really, that doesn't stay very small and stand alone.