What is the proper way of using existing fields?
Should I create "Written by" field (term-reference to Authors) for each content-type or create the field for one content-type and use it in other content types?


If you need to collect the same information for different content types, you should use a single field. Your "Written by" field sounds like the perfect case for that. If you had different vocabularies for your authors, say "Book author", "Article author", etc, you'd want (and need) to use separate fields for each.


  What are advantages/disadvantages of either methods?


One advantage is that you can query all content types by the one field. So if you find yourself wanting to view all content written by a single author, or even all content written by all authors, it will be easy to create a view to do that. But that's only useful if you need it, obviously. I suppose the main point is that the use case of the field itself will actually dictate the relative advantages/disadvantages of either method.

Also, whenever you create a field, you create two database tables (one for current data, one for revision data). There are, shall we say, "mixed" feelings about whether this method of storage is the best idea from a performance standpoint, and some people prefer to keep the number of tables down.  When you attach an existing field to another content type, the same database table is used for all of them, so that box gets ticked. Again though, this only makes sense when your data can be separated.


  What happens if I delete a reused-field from one content-type? Does it get deleted in all others?


The field will only be deleted once it has been detached from all content types. Data that belongs to the content type from which you detached the field will be moved into a deleted data table, and purged during cron runs.

On to case 2, and just ask ask yourself this...

Keeping in mind that you can have different labels for each content type's instance of the same field, will that give you enough of a visual (or data-led) cue to let you know the differences between the data? 

If so, use a single date field to gain the advantages mentioned above. If not, then it makes more sense to your data design to have separate fields.

It all comes down to what's appropriate for your particular website, but hopefully the above will give you some sort of way forward.