Project Plan in Agile

If you have an ordered Product Backlog with clear, concise Product Backlog Items written in a way that is accessible to stakeholders, a clear expression of a Product Goal representing the current longer-term objective for the Scrum Team(s) working on the product, a Sprint Backlog showing a clear expression of a Sprint Goal and a plan for the team to achieve that goal, would any contents of a project plan add any more value for stakeholders?

I would say that many, but not all, contents of a typical project plan are either represented through the other Scrum artifacts or are unnecessary. That doesn't mean having some aspects of the team's way of working written down isn't helpful. A description of the team's implementation of Scrum, for example - when and where the Scrum events happen, duration of Sprints, the team's Definition of Done, where to go to find the most up-to-date Product Backlog, any additional documents or artifacts that are needed to make the product useful and usable and how those are maintained and distributed are a few examples of elements of a project plan that may still be useful in Scrum. Whether these live in a formal project plan or a more lightweight form depends on the context.

is it really necessary to create a separate project plan as we do in water fall model like activities, start date, end date, percentage of completion etc.

Usually, it is neither necessary nor wise to encourage fake certainty about such things. With complex work, it's better to offer evidence-based forecasts using measures such as velocity or throughput in conjunction with an emergent Product Backlog.

Why would you need the extra work of creating that plan for every Sprint?  If your Sprint Backlog is visible, you should be able to see the all of that information.  Percentage completed is determined each day during the Daily Scrum by the Developers for each item and for the entire Sprint. Start and end dates are defined by the Sprint timebox.  

Some teams will use burn-down or burn-up charts to get an idea of their progress. I personally don't like them unless you are "burning" the items themselves and not something like Story Points or estimates.  

During your studies of the Scrum Guide for the 5 certifications you have achieved, did you ever see anything that would indicate that such a project plan would be needed or even worth creating?

In an audit context, I feel it is better to keep a formal project plan. 

Why?  If the audit is focused on how the work was done, the formal project plan would not be completely truthful because you would create it after the work was completed in order for it to be accurate. That would be a false representation. 

How often are audits done? Does your organization do regular audits of deliverables?  If the company is using Scrum broadly, their audit team should be aware of how the framework enables work to be done and audit appropriately.  If I were part of an audit team that was auditing an organization that claimed to be agile and used the Scrum framework, I would be suspicious if a formal project plan was presented to me. 

I agree very strongly with Daniel. I've spent a lot of time working in regulated industries as well as serving customers in regulated industries, which means a lot of audits. Although "project plans" are an example, I don't think I've explicitly been asked for a project plan. Instead, auditors have asked to see how we plan, how we monitor against the plan, and how we improve for future plans. In the context of the Scrum framework, the Product Backlog, Sprint Planning, the Sprint Backlog, the Sprint Review, and the Sprint Retrospective address their concerns quite well and don't require additional work to create documents beyond what the team needs to work in Scrum.