3rd reason why a forecast may not come true - the inherent uncertainty
You rightly used the word "forecast"! Prior to 2011 the Scrum Guide had the word "commitment". That caused two problems:
The development teams were under pressure to deliver on the "commitment" at all costs. Often this cost would be a drop in quality.
The Product Owner and the stake holders would make downstream planning, such as product launches and client commitments based on the hard "Commitment" by the development team.
In spite of the best efforts by the development team to estimate carefully and their best efforts to deliver on the commitment the work may not be completed.
In one of my previous projects we were building a secure application for online banking. We had selected an open source SSL toolkit for the encryption. We ran into a problem. Even though our lead developer was highy skilled and made every effort to make this functionality work or find a work around we could not do so. We identified that it was a bug in the open source software. Eventually our lead developer fixed the bug in the open source toolkit and contributed the bug fix back to that project. It was gratefully accepted. But, our project did take a hit on the time line.
You can read more about the background to the change in the Scrum Guide from "commitment" to "forecast" here:
Commitment vs Forecast: A subtle but important change to Scrum
However, it is possible in your team there is a pattern of poor estimation or reduced productivity, beyond this inherent uncertainty.
Only a subjective expert estimation can be applicable to this
situation (in other words, talk with the developers, and ask why their
forecast didn't come true)?
Your comment above seems to indicate a command-and control style of approach where someone from outside the team (expert) would monitor and control the team. The Scrum approach is for the team to identify the issue in the sprint retrospective and come up with ways to overcome it.