I feel weirdly fortunate I came up working on open source CMSes in the late 00's --- the docs were typically woefully inadequate, but it taught me to read source and then drop debuggers and trace to confirm my theories about how the source behaved. Often when I see programmers hit a wall, they are for some reason stuck on poking at the underlying code like a black box instead of just trying to understand it. And understanding complex code is hard intellectual work, but to me it's always been more fun than the guess and test of pretending the source is closed.
I've been shifting a bunch of data analysis out of spreadsheets (and some adhoc SQL) to Jupyter/Pandas, and we've found some unexpected tradeoffs on both sides.
The lack of testability and version control (and really, long-term maintainability) is what drove us out of spreadsheets into Jupyter. We've found though that the workflow in Jupyter, even with Pandas, is not great for exploring and getting a feel for data --- we end up missing the very quick "poking around" you can do in excel or in a good sql client.
I'd have to use Stencila more to know if it strikes the right balance for the kind of analysis work I do, but I'm glad to see such a thoughtful attempt to try a new balance.
The one use I've seen there is helping people notice cross-cutting concerns that might need to be pulled out --- to do that though, you need to setup the standup in a pretty particular way, beyond just "here's what I plan to do today"