The simplest reason is that it lets you define a clear sequence of execution for functions that may fail without needing to nest conditional checks.
In the example you’re fetching a page (page may not exists), then authorizing the current user to interact with that page (user may not be authorized), then updating the page (update may be invalid).
You could nest three ifs, “if page is not found fail, else if user is not authorized fail, else if page cannot be updated fail, else put flash and redirect”, but then all the error handling obscures what you’re actually trying to achieve.
with allows you to structure it as “successfully get the page, then ensure the user is authorized, then update the page, then put flash and redirect”. That way the happy path is clear to see, but you haven’t ignored the fact that things can go wrong because you’re still checking for that, just not handling it right there.
You could just as easily not put it in the with, but there’s a non-technical reason you might want to put it in there.
Since the with is defining the logic for some process, in this case how you update a page, and getting a page is a fundamental part of the process as they’re defining it, then including it in the with puts all the steps of the process at the same level so that it’s clear to understand each stage of the process.
It’s a decision entirely aimed towards trying to present something clearly for the developer, and it might not always be the clearest choice given a team’s conventions.
Everything defined between with and do is available in the do block (but not in the else block, if there is one), and if you reach the do block it means there were no errors before.
