My answer and some associated comments (1, 2, 3, 4) appear to have sparked this question.
The original question presented a very specific case - a Scrum team has met their Sprint Goals before the timebox for the Sprint has elapsed. All of the forecast work has been completed and meets the team's Definition of Done. The team is now wondering what they should do between this particular point in time and the conclusion of the Sprint (the Sprint Review and Retrospective).
This situation is not discussed in the current (July 2016) version of the Scrum Guide. For the case of multi-team environments, this particular case is also not discussed in the current (August 2015) version of the Nexus Guide.
I believe the next place to turn to would be the Manifesto for Agile Software Development and the principles behind the Agile Manifesto.
What these guides, manifestos, and principles say to me is this:
The primary goal of an organization that is agile is to satisfy customers and users by delivering valuable software frequently. Scrum realizes these two principles through Sprints, each of which produces a Potentially Releasable Increment. When you have multiple teams coordinating, you integrate the work of all the teams and ensure it is releasable at the end of every Sprint (Nexus gives us more specific guidance and advice, but there are also other frameworks to scale Scrum specifically or agile methods generally).
By overforecasting, one team has put themselves in a position that is not sustainable in the long term. However, sustainability is much lower on the list of principles customer satisfaction, delivery, collaboration, and support and trust. I'm not sure if the list of principles is an ordered list or not, but it seems plausible that it is. Because of the emphasis on delivery of software and customer satisfaction, those need to be the immediate concern of all of the teams involved.
Another agile principle is about giving the development team the support they need and trust to get the job done. That support may come from management or it may come from another team. However, help cannot be forced upon the team - it must be offered and accepted. It may be too risky to add new developers to the mix. They may not have the right knowledge, skills, personality or temperament, and so on to provide valuable help. The team that has overforecast should be aware that one or more members of another team are available and then be trusted to make the right decision that allows for the successful completion of a Potentially Releasable Increment at the end of the Sprint.
After the immediate concerns have been addressed - either getting help to complete the Sprint Goals or not - the Scrum teams can turn to reflecting and adjusting. Again, Scrum has the Sprint Retrospective to do this. The Scrum Master role should also be involved to ensure that the teams learn from the events and adjust their upcoming behavior (how they plan and execute future Sprints). This is the point at which the team that overforecast and the team that underforecast adjust and try to return to a sustainable development pace.
Now, a lot of this does center on an assumption - the Scrum Teams are working on a single product. What if they aren't? Even so, the teams are part of a common organization. This isn't just about satisfying one particular customer or user base. It's about the organization being customer-centric and the individuals and teams that are in the organization responding to changes in the environment around them.
One team providing resources to help another team is only one option. There are others that may also be valuable, but cross-team help is in line with agile principles and should be on the table. So...yes, it may make sense for one Scrum team to provide resources to assist with another Scrum team. This shouldn't be considered the only way to share knowledge across teams, though. Also, since Sprints are projects, adding more people to a late project may make the project later. It's about balancing risks with rewards to meet the desired objectives.