I've noticed that several sources encourage developers to only use a single activity in their projects. When would it be appropriate to have more than 1 activity in a project? Is there a limit to the number of composables an activity can have? 1 concern I have is for a large project requiring multiple screens, this can lead to heaps of code which eventually will become time consuming and difficult to scroll through and find.
It is not a particularly bad practice to make your app multi-activity-embedded, but the thing is -- In most of the cases, you do not need it. The users do not know what an activity is, since they simply look at the app in terms of the screens that the app offers. Therein lies the explanation. A single Composable can represent an entire screen super-easily, it's barely an inconvenience.
HENCE, the entire idea and need of multiple activities gets destroyed. Single activity apps are more efficient too, since there's only one activity so you do not have to explicitly handle the data-flow between various activities. This means a single ViewModel, minimal coupling, high code-readability, and easy data-flow.
This is the same reason that fragments are discouraged too. They often involve multiple viewModels which complicates things. When a Composable can accomplish everything on its own, it automatically becomes the best choice for developers to use to build screens. I would highly recommend, no matter the size of your project, that you stick to a single activity.
I can understand your viewpoint as well, and I have something to help.
The Navigation Codelab clearly and simply explains the Navigation System in Compose, which is a framework that basically allows you to create multiple screen-representing (or other) Composables, and then navigate to and from them from anywhere IN THE OS! It is actually super-easy to use, barely an inconvenience.