You can just put meshes in the world, true. But then they’ll be just meshes in the world, nothing else, they can’t do anything.
If you want to give them interactivity or have them do something, you create an actor blueprint and add a mesh component so you can script/program some behavior for it.
If you want trees in your world have leafs fall when running below them, you can’t do that with just a tree mesh that you place in the level. The mesh alone doesn’t do anything. You’d create a “tree” actor, with a mesh component (the tree mesh), a particle generator component(that spawns the falling leafs), and a trigger zone box component.
Then you script an event “onComponentOverlap” for the triggerbox component that causes it to start the particle generator for a few seconds.
About the cameras :
It all comes down to how you want your game to work.
If your games character is always the same and no other character in the game is the same as you, then you can place the camera in that actors blueprint.
Personally, i like to separate the camera actor from the player character actor (2 separate actors) and just script the camera actor to follow the player character actor.
That way i can reuse the player character actor as an NPC without the NPC then having unused camera components (which would waste memory and cpu time) and even if i don’t reuse the character, i have a clear separation between the camera and the player character, which i think is good to have.
The content browser is for everything, stuff you can place in the world and stuff that can’t be placed but is used by other things that can or can not be placed in the world or spawns on runtime.
Just keep your stuff organized (by creating a smart folder structure) so you don’t get confused. Personally, i like to group things by classification, so i put static meshes in a different folder than character blueprints, i put materials in another folder than sounds, etc.