Best way to set up data architecture
There are quite a few possibilities to deal with this.

To get an overview:


The advantage of custom entities is that they don't come with all the overhead that nodes have. They're especially well suited for storing and managing completely custom data that you might not even want to display and you have full control over them (their data structure, workflows, UI). The commerce project for example defines own entities for orders, products, line items and so on.
Nodes are still the main content pieces. They provide various features that you don't yet get for free with custom entities, like revisioning and comments. Various additional modules focus on nodes. In short, you get a ton of features, but have to live with the overhead that comes with them. Every additional data structure you need is a field, living in it's own table, and so on.
Entity API provides a lot of features for custom entities, for example CRUD and allows you to easily integrate with various important tools like Views and Rules. It's definitely worth to rely on it, see http://www.trellon.com/content/blog/creating-own-entities-entity-api for a nice introduction.
To connect entities (Hint: nodes are entities as well), you can for example use  Entity reference (simple, directed relationship) or Relation (flexible, unidirectional relation between entities which is an fieldable entity on it's own).


Some specific tips based on that:


Article sounds like a perfect use case to use nodes/a content type to me. People need an UI to create them, you might need revisions, maybe comments, they need to be displayed, probably want nice aliases (Pathauto) for them and so on.
Author; Here you have a bunch of options. Nodes have an author by default, the user that created them. Users can have fields as well and can have a public profile, so your authors could actually be users. Especially if your authors are going to be the uses which will create the articles on your site themself. If not, then this might not be a perfect match because changing the author of a node requires administrative permissions. If not, you could either use another content type if you think that makes sense or create a custom entity.
Location: The traditional answer are certainly taxonomies. They're still a good match to categorize content, provide a number of possibly useful features out of the box, like hierarchy (so you could do do Country > State > City), auto-create new locations from a autocomplete widget and a list of nodes attached to them. And, they're fieldable entities too (surprise!), so you can store additional information for them as well.


So, to me it sounds like the default entities provided by Drupal core are a pretty good match for your data.