First thing first, don’t worry about performance unless it’s actually an issue. Run the simplest to write version of the code on your target platform and see if it’s fast enough. If it is, don’t make life harder by unnecessarily optimising it.
Aside from that, it depends on your requirements.
If performance is critical and your task is specific and exactly the same for all objects, I’d look at having a controller class which updates them all centrally in as tight a loop as possible. That is, make a central script that has an array of targetDirs, targetRotations and references to transforms, and a loop which applies the update to all of them at once. This won’t be as optimal as if you did it at the engine level, but it’d at least reduce the overhead of having 199 extra scripts being managed by the engine to do the same thing.
Having said that, do a benchmark test to see if it actually makes a difference. That is, put 200 (better yet, 2000, or 20000) objects in a scene with your script and check out the frame rate (better yet, the Profiler if you have Pro) on your target platform, then write a centralised object that does the same thing for the same number of objects from a single script and see how that performs. If the difference is significant, use whichever is faster. If the difference is negligible, use whichever has more maintainable code.
If you add extra features to that bit of code later on, do the benchmark again, because it can change the performance characteristics. You especially probably want to avoid adding branches (“if statements”) inside the loop, but again that’s worth testing. Performance depends on too many things to make assumptions about what will impact performance and how - compiler optimisations, JIT behaviour, target platform characteristics…
If the behaviour of your 200 objects isn’t going to remain as trivial as your example, then just writing your scripts as usual and letting Unity manage it is probably the best way to go. After all, that’s what it’s designed for.