When should you create additional domain in forest?

Creating another domain adds complexity. To the extent that you are able to maintain a single domain environment you will limit complexity. I find that administrative activities are easier in a single domain environment.

Visual organization ("a tidier organization") could be accomplished with other features, like organizational units (OUs) in Active Directory. Personally, I wouldn't consider such "tidiness" reason enough to create a second domain.

Just about any delegation of control scenario that you can envision in a multi-domain environment can be handled in a single domain by delegating control at an OU.

From a logon efficiency perspective it makes sense to have Domain Controller (DC) computers at a location for whatever domains will be used in that location. If you are going to have users travelling between locations you will need more DCs (one for each domain, at minimum) if you have a multi-domain environment.

Cross-forest Group Policy Objects (GPOs) have, in my experience, been somewhat flaky. You will need a DC from the domain where a GPO is hosted well-connected to machines that apply GPOs from that domain. That may also cause to need more DCs in a multi-domain environment as compared to a single domain.

My opinion is that a multi-domain environment is only necessary when you require multiple domain-level password policies (and can't make use of fine-grained password policy within a single domain for some technical reason), or when the domain replication traffic would be so extreme as to warrant isolation to limit replication traffic.

Edit:

If you really do need separation, legally or organizationally, then a separate Forest for the other company is really the only way to go. Separate domains in the same forest offer no practical separation, aside from partitioning the replication of the Directory.

As your question is currently posed, it sounds to me like you could get as much mileage out of setting up a new Site in Active Directory as you would with a new domain. You'd create a new domain controller at the new physical location, but in the same domain and forest, and set it up to serve the new site in question (through the Active Directory Sites and Services management tool).

Of course, without a clarification on Mathias' comment, I'm not comfortable saying that with any certainty. If these really are two different companies, you should probably have a forest for each company, even if they collaborate tightly. Binding them into one AD forest could have undesirable legal or compliance implications that might outweigh the advantage of simple Active Directory management. And then there's the question of what happens when/if these two companies go their separate ways. Who "owns" the existing forest, how do you perform proper disengagement, who pays for that work, and who pays to set up a new forest for the company that now doesn't have one?

Federated services exist precisely to allow for interaction between companies' forests and cross-use of resources in those different forests, so that separate organizations don't need to share the same forest to work together. It a more complicated setup, and more to manage, but if there really are two companies in play here, it's the setup I'd recommend - two separate forests using federated services to connect to each other. Less hassle, mess and politics involved when each organization owns their own forest, and connect to each other using federated services, and no worries about what happens after the collaboration ends.

It sounds like most of your questions need to be directed at a business level rather than technical. Firstly, if the business intends to grow the second company and then separate when they are grown up, a separate domain could be useful in that scenario in order to help them split.

Unless you have hard security requirements never use a RODC they are just another administrative overhead and not worth the bother in almost all scenarios. Great in theory, painful in practice. At least lab and understand what you are getting into before you do it anyway.

If the companies intend to stay together it will depend how separated the IT administration will need to be. A domain admin is a commonly used, often overused but also often necessary for key staff in the IT organisation. A single domain means tht this powerful user group will allow full access within that domain to a great many admin consoles and cover both parts of the company. Changing those defaults where it is allowed can be even more messy than the extra admin effort of managing 2 child domains. So if you believe there will be a requirement to split administrative responsibility and this level of control (per company) is likely to become a hard requirement, then separate domains is the way. If that will never happen and 2 IT orgnisations can work in harmony (good communication and collaborative change control the key here), or only 1 IT org can handle/share the 2 companies then stick to one.

I am currently helping a company with around 12 separate domains, regional IT support and 60000+ users consolidate into a single domain again because they don't have the need to remain separate and it is a painful process. So the early decisions need to be the right ones and while you can't always plan for what the business might do in 10 or even 5 years time, ask questions at all levels now, document their responses and prepare well.