Enlarge or split the team

Our company wants to add 2 more people to our team to speed things up

Doesn’t your company want to have competent, self-organizing Scrum teams which decide for themselves how best to improve value? If not, why not?

But in terms of Scrum a devteam consists out of 3 to 9 people.

Scrum does not limit development teams to between 3 and 9 people. Scrum tends to be optimized for a Development Team with between 3 and 9 people. If you have fewer than 3 people or more than 9 people on the Development Team, you may not realize the full benefits of all of the Scrum events and artifacts.

What does Scrum theory advise, split or enlarge?

Scrum calls for self-organizing teams. If the team identifies problems and one possible solution may be to grow the team or to split the team, then the Scrum Master should work with both the Scrum Team and the organization to determine other possible solutions and enact one, while ensuring that the Scrum Team remains productive

What would you guys practically advise?

First, I'd want to know more. Is this intended to be a permanent growth of the Development Team? Or is the company looking to expand and start a second Scrum Team? If it's the former, then it doesn't seem like the company is embracing a number of agile and Scrum principles. If it's the latter, that should be communicated with the team and worked out in a manner that limits interruptions to development - it may need to happen for logistical reasoning to support onboarding of new staff to the company.

The only advice that I'd have is that the Scrum Master should be carrying out his services to the organization - leading and coaching in the adoption of Scrum, planning Scrum implementations, causing changes that increase the productivity of the Scrum Team, and helping all stakeholders to understand Scrum. Adding people to a project to improve performance is a myth. It's going to hurt immediate productivity as these people are brought up to speed and the larger Development Team is going to have an impact on the efficiency of the various Scrum Events even in the long-term - these risks should be raised to the organization and accepted or mitigated somehow.

Aside from the other nice answers, and with total lack of knowledge on your scrum performance, teams, etc, my practical advise would be to go gradually whenever possible.

Let the two new members share one or two sprints with the team. Then, when the team feels prepared at the end of a sprint, go and split it in two self-organized teams based on their own judgement. Generally, adding new people won't increase the productivity but won't either increase the overhead of coordination to the point of a catastrophe.

I've read this approach in the Nexus Framework for Scaling Scrum book. If you are planning on scaling scrum at a serious level this book is worth reading.