If a requirement is discovered in the middle of a project or even later, then the cost of implementation of this requirement can be very high.
The Scrum suggets that we should only refine the top PBIs of the Product Backlog. The other PBIs are not refined, and thus the requirements related to these PBIs will be discovered lately in the project execution.
What is the Scrum's approach to this?
If a requirement is discovered in the middle of a project or even later, then the cost of implementation of this requirement can be very high.
In this statement you are saying that the cost of change is high (particularly late on in a project).
The agile approach recognises that change happens and so endeavours to reduce the cost of change.
This is the fundamental difference between the agile approach and traditional development:
Traditional development: Let's get really good at predicting what will happen (plan well)
Agile development: Let's get really good at responding to change (respond well)
Prioritisation, continuous delivery and review is the way to control delivery risk for any software development, not just when using Scrum. I can't agree with the first sentence of your question however. If work is ordered wisely then the most important and most risky or expensive work usually comes first, so the cost of unexpected work should tend to reduce as time goes on rather than increase. An experienced team will also try to identify for early refinement any items that have broad architectural impact or have lots of dependencies.
No method provides a guarantee against the unexpected but continuous delivery helps avoid nasty surprises by testing the product early and often. That's usually a much more reliable method than trusting early analysis alone to identify issues.
You say:
If a requirement is discovered in the middle of a project or even later, then the cost of implementation of this requirement can be very high.
This can be true or can be false. It depends of the type of change you are referring to. I'm assuming a big change, or something lacking in an important way, or something that deviates in some way from what you have built up to that point. If this is the case, then yes, the change can be expensive. If it's just a requirement like others similar, then implementation will probably not be that high.
The way you phrased that first sentence and the rest of the question implies you are using a predictive approach, or a traditional approach in which you gather requirements at the beginning and then you build a plan to have then implemented. Only in that way can you talk about "the middle of the project".
If you are building the product in an agile way for example, you wouldn't know you are in the middle of the project because you are focusing on delivering value, not on timelines that tell you where you are in the project. However, this does not mean that using Agile or Scrum will guarantee that a requirement late in development will be cheap to implement. If you are building a white airplane and at some point you discover you need a submarine, you can't just chop off its wings, paint it black, and call it done. This kind of change will mess up your implementation no matter if you are using a traditional approach or an Agile one.
However, what Agile does, is that it allows you to figure out sooner that you need a submarine instead of an airplane, because you are incrementally and iteratively building stuff that you can collect feedback on and learn of what's needed, instead of assuming that you know everything from the beginning and you can specify it in requirements that won't change or are not lacking in some way. As already mentioned in the other answers, the Agile approach is different and reduces the chances of discovering something that can really be very expensive to implement at some point down the road.
From a sequential perspective, the idea that a requirement that is discovered later in the project is likely to be more expensive to address. Similarly, a defect found late after origination is also likely to be more expensive. This is because of how much work is done. Consider that in efforts run using sequential methods, you try to elicit all of the requirements early. Then, you create an architecture and design that addresses all of those requirements. Then you implement the selected design. A change, especially a new requirement or a modification to an existing requirement, requires analyzing the full set of requirements for issues and conflicts, then analyzing and updating the architecture and design, then updating the implementation, and then the tests. Changes ripple throughout each phase of the life cycle and all associated artifacts.
Scrum, and the majority of other agile methods, takes a different approach. There is just enough architecture and design to support the known requirements. The system evolves over time to accommodate new or modified requirements. That doesn't mean that a radically different requirement won't cause a large amount of rework, but the risk is reduced. By building incrementally and getting feedback to build what is perceived as the most important thing next, the chances of something that is very important but also very difficult to implement will be reduced. Any rework will be limited to the parts of the system already built, rather than rippling through many phases of development.
I would also add that as complexity increases, the cost of changing the functionality of the system does get more costly. However, using incremental design, keeping the design simple (think principles like KISS and YAGNI), and paying down technical debt early can make future changes less costly. The complexity that exists should shift more toward essential complexity as opposed to accidental complexity.
