Again, this will depend on the size of the team. Planning on a longer time window while giving dev teams a time to coordinate, get everybody on the same page about what you're doing and why...works. It works extremely well.
It gets the plan in front of everybody so you can discuss the tradeoffs and risks too. There's an entire open session as part of it called R.O.A.M. where risks to the ability to deliver the plan are discussed, not just with the tech people but with the business folks too.
That portion of PI planning is where you call out things that could break the plan. Emerging (or sustainment) work is one of those risks and you have to call it out, then once it's called out you have to discuss what the organization is going to do to prevent it. Capacity isn't going to just spring forth out of nowhere, so what are we pushing off if there's more of it than expected? Do we need to prioritize preventative work to make sure we don't have problems? Do we need some type of infrastructure, monitoring system or automation in our devops process?
Everywhere I've been, the PI Planning process has led to less "we have to do this now" and more "we need to see if this can be included in the next PI", which creates significantly less disruptions to the development team focus. The only remaining interruptions should be production issues (preventable) or significant market shifts (rare).
It doesn't work when people try to adhere to that plan so rigidly that it becomes a waterfall system.