Edit: @kweso has a good point with the "Children" option of the tag. And obviously I took too long to write my answer. Anyway, I wrote it, so here it is anyway...
Edit 2: I hope @kweso doesn't mind. But the iterate function is... well, lets say not so good. It's a recursive hierarchy iteration, which kind of proves my point in the last paragraph. Given a "nice" hierarchy it will simply crash C4D.
Original post
Consider it as the equivalent to one of Cerbera's answers on Polygon modeling. I do not want to imply similar execellency, though.
Usually such questions are best asked in Maxon's Plugin Café. Support there is provided by Maxon for free.
Community member @Cairyn provides a very nice Python tutorial over at Patreon. There you could learn all you need.
Also Maxon provides a bunch of examples over on GitHub. These are also included in the Python SDK download.
For your first Python script you already came a long way.
In general I'd say it's maybe not the best approach to try to piece it together with "CallCommand()" (reasons below).
I was too lazy to look up
c4d.CallCommand(465000402) #thought this might work
Would have been cool to have a comment, which command it actually is.
At first I even doubted you could succeed with "CallCommand()" for the "copy tag to children" part. But after looking it up, I learned, there actually is a command for that as well:
c4d.CallCommand(100004777) # Copy Tag to Children
So your remaining problem, will be to find the tag(s) (basically loop over them), select them and then call the above command per selected tag.
Functions to look up to tackle this:
BaseObject.GetFirstTag()
BaseObject.GetTag()
BaseObject.GetTags()
When looking at cloning tags, you need to be aware though, there are also hidden tags...
Now, why do I regard this approach as suboptimal?
"CallCommand()" basically simulates user clicks to menus and buttons.
Consequences are:
It can not be guided easily and precisely, nor can it be customized
It adds an Undo step per call (so in order to undo only the script you posted above, you already need to press undo five times. And this still ignores, the inserted camera and changed render settings have not even been added to the undo stack. I do get though, in case of importing a new project file, this does not matter too much.
Adding to the previous point, mixing "CallCommand()" with your own custom undo handling is usually a bad idea.
Your script relies on the imported project to have a very specific structure. If there is only one additional object in there and this object happens to preceed the object you are aiming at, the script will fail.
Simulating user clicks, you always need to make sure, you prepare the environment in a way, that such clicks can be successful (objects selected, tags selected,...).
There is no feedback. You have no idea if a command failed or the reason thereof.
Using an importer via "CallCommand()" you loose the chance for additional workflow optimizations. For example, I's assume, you will always use the same parameters for import. But with "CallCommand()" you have no means to suppress the importer dialog (not talking about the file requester)
Probably a few more disadvantages...
My advice would be to ditch "CallCommand()" completely for a script like this.
Instead:
It's easier and more reliable to do the import directly (there's an example for this in Maxon's above linked GitHub repository).
Get hold of the actual root object you want to be working with (examples for this can be found all over all places I mentioned)
Create the tag manually (you already achieved a similar thing, when creating the camera
Insert the tag manually where needed. Depending on the complexity of the hierarchy, this can be a little bit more tricky. But again code snippets doing so are all over the place.
Save
(bonus) you could then slap a little undo handling on top
(bonus) depending on your needs, the imported document wouldn't even need to appear in C4D (just a thinking, because you save in the end, maybe you only want a automatic converter in background
Result: Feeling proud of yourself, because you created your own shiny little helper which acts similar to native commands
Lastly, the inevitable self advertising:
I do such things on "pay what you want" basis. A script like this would be maybe half an hour of work. And you can also book me for 1:1 Python introduction/training.
I can already hear: "Why did he write such a long post? Instead he could have simply posted the script!"
Yes, I could have, but I prefer people to learn something. And there are way too many shitty scripts out there, which were obviously pieced together via copy/paste without the creator even understanding a single line of what he did.
Fascinating for me, the worse such script, the more people like it and the more it gets spread around.