Reading code is harder than writing code, right? And handing code over to some one else is inherently handing it over to some one who does not have the experience or knowledge you gained writing it. If you want that person to be successful then there is pressure to make that code simple. The author thinks that pressure causes the code to also be poorly or naively engineered. I don't think the idea is that handing over code is bad, but that a team should maintain responsibility for a product over time (because they can take advantage of their domain knowledge) instead of handing it over (like it was a finished product, when it isnt).
While it's not as drastic a handoff, handing code from your present self to your future self is also important. I find myself thanking my past self out loud and by name at times.
That's the main reason for DevOps, as I understand it: one team develops and operates the product. And in the case of DevSecOps, also secures it, rather than a separate team doing so. Some individuals will specialize, but a cross-trained core team ties both (or all three) of these functions together throughout the product's life cycle.