Scrum : Not Allowed on Scrum and Mandatory but Allowed List

What is your reasoning behind why such things are either allowed or not allowed?

All of the items listed are not part of Scrum. The items in your first list, with the exception of project managers, generally do more harm than good and are considered anti-patterns. In other words, anything that impacts empiricism or self-management might appear there. 

Items that could be added to the first list include (in addition to what you noted) "definition of ready", design sprints, stand-ups, and demos.

A project manager could exist in an organization and be helpful to a Scrum Team, even though that isn't listed as one of the three Scrum accountabilities. Helping a Product Owner with budgets might be a healthy example. Then again a Scrum Master in name only, disguised and acting as a project manager, might do a lot of harm.

The second list of items can be considered not Scrum but complementary to Scrum. There are hundreds of items that could be added. I would suggest additional items such as Kanban and Flow metrics and practices (e.g. limiting WIP, cycle time, work item aging), CFDs, Vision statements, XP practices, Dev Ops, Lean UX practices, Lean canvas, impact mapping, story mapping, specification by example, acceptance criteria, velocity spikes, etc.

Some items that are complementary to Scrum might help one team yet hinder another and be harmful. We've all heard of situations where velocity has been misused to compare one team against another. Story Points become inflated, or teams are taught that that story points are the only way to understand the effort and never explore other techniques (e.g throughput, T-shirt sizing, right-sizing, same-sizing, etc). I've seen Product Backlogs where every item literally starts with "As a user...". And "spikes" misused to the point where it becomes Scrumer-fall.

I feel that both of your lists are wrong.  As a framework, Scrum doesn't require or disallow anything.  All of the things you listed are related to processes.  The Scrum framework does not dictate process.  There could be an argument that the Sprint and the contained events might be a process. But since there is a not a step-by-step listing or any specific requirements made, I don't see them as a process.  

Scrum provides guidance on how a team can be effective at adapting to changes. The actual activities, processes, techniques that are employed are up to the Scrum Team to decide.  I have worked with teams that have allocated Sprints to hardening a code base before a final big release.  But that was their decision to do at the time, not something that was built into "the plan" and required. I have also worked with teams using a lot of your "allowed" items that have struggled to be productive. 

As you move to Scrum Master from Project Manager, you need to understand one thing.  The two are completely different in nature.  Project Plans are more regimented and long term focused. Scrum is adaptive and short team focused with a goal of longer term.  Scrum is about inspection and adaption, Project Planning is more about planning and protecting that plan.  Project Managers are focused on executing the plan and helping the team reach the end.  Scrum Masters are focused on helping teams be self-managing, self-organizing, adaptive and helping them become successful at delivering incremental value to the stakeholders. This doesn't mean that practices from both could not be used complimentary.  But you have to take into account which of the philosophies is the most important when incorporating the two together.

There are some mandatory things too:

3 roles, 3 artifacts, 5 events, and 3 commitments (now).  

Using the rules laid out in the scrum guide.

One thing that is allowed is to practice scrum ineffectively, which may occur if you use sprint 0, hardening sprints, and the other things you mentioned as not permitted.  So yes, you can do anything you want except violate the scrum guide, even things that run a risk of making your scrum practice bad.

At least that's my opinion and advice.

And by the way, Rodolfo, I like what you have. For people who aren't inclined to geek out into the philosophy of scrum, you're pretty good in your lists except that managers are still important (see the PAL course).  

Again IMHO.