Splitting scrum team into smaller teams

How many total people do you have? Are the people able to self-organize into smaller teams?

Once you reach 3 teams, you can begin to look at more structured approaches for scaling. Some options include Nexus and LeSS. However, you can also look at applying dynamic reteaming approaches, the idea of fluid Scrum Teams, or FAST Agile. Whether you go with stable or dynamic teams depends on the organizational context, but you have choices. If you do go with more dynamic teams, some of the LeSS structures may still be useful, but you'd have to make changes for dynamic teams instead of the stable teams that LeSS defines.

How do you suggest to deal with scrum events such as planning, sprint reviews and retrospectives, should they be held separately for each team or together?

Try to keep things separate as far as possible, for simplicity. It's best if each team can inspect and adapt locally, with minimal integration dependencies.

Have you taken care to minimize such dependencies? Can each team provide a Done feature-complete increment under its own steam?

This is my favorite principle from the manifesto for agile software development.

Simplicity--the art of maximizing the amount

of work not done--is essential.

As @Ian Mitchell suggests keep it as simple for the teams as possible.  I would also suggest keeping everything separate unless there is a compelling reason for something to be combined.  Then I'd go down the path suggested by @Thomas Owens.  But I would not start with those complexities.  Start simple, inspect and adapt as necessary.

A side note.  If you are splitting one team to multiples but not adding extra Scrum Masters or Product Owners, you will be increasing the work for those two roles. It will become more difficult for them to do any type of extra work.  The Developers may have to participate more by taking on some of the activities that are currently done by the Scrum Master and Product Owner.  Also expect some reduction in the Developers ability to deliver value as they will have to learn new things and adapt their working behaviors.

Splitting the team into multiple Scrum teams and combining the Scrum events may not fulfil the expectation.

combining events may look like minimising the meeting time from the Product Owner and Scrum Master perspective But for developers, they may spend more time than what was suggested in Scrum guide for each event

Probably, Demos part of Sprint review could be one event to merge so all the teams get to know the increments in their product as a whole. Speaking about integration then it should be more a Scaled approaches than just Scrum.

Is the splitting that your team has made the one that best reduces dependencies and integration issues?

As there are less problems with dependencies and integration, the need for coordination will get reduced. The system will be simpler and the necessity to establish common events will decrease.