My opinion - you should implement any security based things that you require. Sounds like a dumb response, but think about it from a hacker perspective. If a hacker gets into your system, what would they have access to and how would that hurt you as a data professional and your company?
If they get in as a sysadmin, they have access to everything, so any protection you have in place is lost BUT the auditing MAY still be helpful. Might not be helpful if the hacker dropped the audit tables, but if they were unaware of the auditing, or didn't think to check for auditing, you may get useful information from the audits.
Now, hopefully your sysadmin accounts are secure. What I mean is they are using secure passwords that are difficult to guess and impossible in a reasonable timeframe to brute force. But what about the average end user? Lets say the hacker gets in as a limited access user. If you don't have row level security, that hacker now has all the data in the table.
It is entirely based on how much risk you are willing to accept. Like if you are storing public information, then row level security may not be needed. BUT if you are storing HR data (for example), having a breach there MAY result in massive lawsuits and someone may be losing their job for setting up the security poorly (it may be you).
BUT, almost any restrictions you put in place will result in some performance hits. The ones you listed should be minor performance hits IF implemented properly.
Always Encrypted is something I would turn on as this protects your data at rest and the performance impact should be very minor. Dynamic Data Masking for example is great for masking data in a SELECT statement while still keeping the data accurate in the database. SSN/SIN numbers are good candidates for data masking.
Implementing security features like row level security or data masking are applied at the table level, so you don't need to apply these across the entire system; just on the data that needs to be protected.
Plus, your list of things you found (the 5 numbered items) I would also recommend for on-prem SQL Instances. They don't ALL need to be implemented, and some databases it may not make sense to implement them. Data Discovery and Classification I would do before doing data masking or row level security as it helps determine which stuff is PII or which tables contain confidential information. Now, on the other hand, if the information wouldn't be useful to hackers (like if you had a database that contained information on plants including name, species, flower colour, etc), then you likely don't need to worry about protecting the data from reads, BUT you would probably still want to restrict who can write to the database and will probably still want auditing in place.
On top of my above advice, if nobody is using the system yet, then nobody will notice the performance impact of turning any of those on!