Develop and deliver at least one piece of functionality in a Sprint.

I don't agree with your assessment.

The objective of a Sprint is to achieve the Sprint Goal. In my experience, the Sprint Goal is often achieved by getting one or more Product Backlog Items to a Done state. The creation of the Sprint Goal and the selection of Product Backlog Items to support that goal are a collaborative effort between the Product Owner and Developers.

It's important to understand that the Sprint Goal isn't the output of some or all Product Backlog Items. A well-crafted Sprint Goal describes some kind of value that the stakeholders will get out of the Increment by the end of the Sprint. If the team is using measures such as capacity and velocity, I encourage the team to make the Sprint Goal something that is achievable with about 60-75% of their capacity, to account for the unexpected, especially if there isn't historical data about the team's performance in the current organizational and product context.

It should be safe to say that if the team isn't achieving its goals, which are tied to stakeholder value, it doesn't make much sense to keep funding the team to develop the product. The team should regularly and consistently be delivering Increments of value to stakeholders.

There is a special case of the first Sprint, which is particularly a special case in the development of a brand new product. The first Sprint is the first opportunity for the Developers to deliver something of value to the stakeholders and then review their work and realign on expectations and objectives. Unless the team delivers something that stakeholders can actually use, it is very difficult for the stakeholders to review their progress and collaborate with the Scrum Team to adapt the Product Backlog for future iterations. In order for the stakeholders to use something, it must have functionality. Therefore, I'd agree with the statement that the goal of the first Sprint should be to deliver some kind of functionality to stakeholders to start the inspection and adaptation process.

Once you have a product, I would consider things like "code refactored" or "improved performance" to be things of value to the stakeholders. I'm not entirely convinced that "code refactored" would make a good Sprint Goal since it doesn't have a direct impact outside of the team. It does have some indirect impacts on the delivery of future work. I'd typically argue that code refactoring should generally be built into other work and the code continuously refactored as necessary. Improving performance, however, does have direct benefits to stakeholders and could be something that can be crafted into a reasonable Sprint Goal. It's a bit too broad by itself, but improving the performance of specific operations or aspects of the system could be seen as valuable.

I do think that the wording in the question could probably be clarified to replace the idea of delivering functionality with delivering something of value. The idea of delivering functionality is more oriented toward output of work, rather than the work as an enabler of outcomes for stakeholders. However, I'm not sure what you can deliver in the first Sprint that isn't some kind of tangible, useful product in order to start the inspection and adaption cycles for upcoming Sprints, wth the emphasis in particular on the output of that very first Sprint for the team.

End of the Sprint, I could have an increment which could have no functionalities added, however it could be more valuable at the end of the Sprint. (E.g. Code refactored, improved performance etc)

Would this allow the empiricism upon which Scrum is founded to be maintained?

I am going to jump on @Thomas Owens' bandwagon.  

2) With the New Scrum Guide, end of the Sprint the increment should be valuable. End of the Sprint, I could have an increment which could have no functionalities added, however it could be more valuable at the end of the Sprint. (E.g. Code refactored, improved performance etc)

So if you went into a Sprint with the intent of adding some new functionality but instead spent the entire Sprint refactoring code, improving performance, etc what was your actual goal?  And why didn't the team focus on that goal?  I would say that this case is something to be discussed during the Sprint Retrospective to understand how and why it happened as it did. Sure the work that you did was valuable but it wasn't the work that the team planned.  From the 2020 Guide section on the Sprint Backlog.

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

It would appear that in your example the Sprint Backlog was not used.

However, if the Sprint Goal was to improve the code base by refactoring and address some performance issues, and the Product Backlog items selected were focused on those things, and your plan for doing the work was satisfied then you have a valuable increment. 

Also, I wonder if you have just found something that hasn't been updated yet.  I imagine that it is quite possible something has slipped through the cracks with all of the updating that had to occur based on the new Guide. 

Thanks Daniel and Thomas. Let me start by saying thank you for taking the time to explain in such details.

I agree with most of the comments made. A well-crafted Sprint Goal will always lead to value that the stakeholders will get from the Increment. No doubts there. And as you both pointed out, its not always adding a functionality which generates value.

For e.g we have been working on a Healthcare system for years now. This system runs validations on millions of transactions every night. We just finished a Sprint which consisted of 14 or 15 Product Backlog items focused on reducing the time needed to process these transactions (which was our Sprint Goal as well). End of the Sprint, the clients loved the improved performance results and the value we created for them.

I now understand the discussion where the first Sprint is special, and teams should add something of tangible value to the stakeholders which they can review and realign on expectations and objectives.  Thank you.

It does become confusing to me cuz we release an updated version of our product every six months. As soon as the version is released and available to the stakeholders, we close the old release and start with a brand-new release, starting with Sprint 1. In such situations our Sprint 1 adds value, not always a functionality.

Anyways i understand better now. Thank you again for your valuable inputs. They go a long way.