The second idea (to create a boolean attribute for selection) has many advantages:
(i) it clearly documents what needs to be labeled,
(ii) it is as permanent and portable as the underlying dataset,
(iii) it provides a simple and direct mechanism to determine which labels will appear (which is even portable to another GIS or plotting package),
(iv) it is even amenable to analysis in case there are ever questions about the relationships between these choices of labels and any other variables, and
(v) by parsimoniously encoding the client's choice, it creates no duplicate information.
There are some general database construction and management principles at work here, as wisely suggested in the question. One of them is that any coherent piece of information should be uniquely represented in the database if possible. (Information used as keys to implement joins and relates of course must appear in multiple places by virtue of its function as identifying corresponding records in different tables.) There are excellent reasons for this principle, as anyone who has attempted to maintain a non-normalized relational database can attest: if you don't consistently remember to update or remove or add this information to every table in which it appears, your database soon becomes internally inconsistent: it's corrupted, often irretrievably so.
Another principle is that in a good relational database design, each table should represent a single conceptual "entity": something that the data are modeling or a relationship among those things. When a client specifies a seemingly arbitrary selection of features, they are effectively specifying a subset of rows in a table. Mathematically, by the axiom of separation this is the same as flagging them with a boolean field. Thus, any meaningful "arbitrary" subset of things in a database can be represented by a boolean field and, conversely, such a field is a good way to store arbitrary subsets (or selections).
Yet another principle is that you should prefer using the underlying data management capabilities of the GIS to store information. The alternative is some ad hoc method based on the capability of the GIS to store information within its "project files" or in some other independent way. A typical example of this is the practice of manually choosing and placing the desired labels. Often it's quick and easy to do this. The problems arise whenever either a change is needed or the work needs to be reproduced; one or the other of these situations is practically inevitable. Manual placement of the labels is tantamount to storing information (namely, what subset of features should be labeled) outside the RDBMS in an extremely elliptical fashion. Namely, the selection specified solely by which labels appear and which ones do not. Think about how you would then solve these follow-on problems:
The client wants the same labels to appear in a related but different map, part of a different project.
A question arises as to whether the labels are associated with some other attribute.
After making several changes to the labels over time, you are asked to revert to the original version.
In these cases, the work involved to solve the problem can be enormous: you have to redo the labeling all over again, or perform manual cross-checks against database tables, or find and restore an old archived project file. If the labels were instead represented by a boolean field in the database, the work would instead be almost trivial.
I would say that upside down text is definitely undesirable, particulary from the map user perspective. Its simply more natural to read from left to right even if the angle of the label is steep. (so my vote goes to the left picture ;) )
In this particular case however... since you have a long label... i would say, that its important to take into account the label startpoint not its centroid, regardless if the label then consequentily turns upside down at some point (if you apply the left-to-right rule), because map users don't start reading the text in the middle of a label but on the beginning.
Bottomline: I think the most important aspect is the maps end user experience, what feels more natural to read.
Best Answer
Depending on the scale of your map, other layers present, etc, etc .... there's a possibility that your labels may be conflicting with each other, or with labels from other features. In the print screen below, you can see that I'm under the "labels" tab. On the bottom left, go to placement properties and set the placements & conflict definition settings (highlighted on the right in the print screen). If you're not familiar, do a read-up in the help menus, or a Google search. You might have to give more weight to the labels for this shapefile (and/or buffer around them - this option also under the highlighted "conflict definition" tab).
OR ..... you could convert your labels to annotation, then place them where you want manually. This would be my first choice. I hope this helps.