Use a label if you need to quickly iterate over all Ford cars or all electric cars. Also labels are a good choice if you e.g. want to apply a unique constraints on all ford cars.
Be aware that writing a label is more expensive than writing a property.
In contrast: if you just need it when assembling the return for a query, you might be better off with properties.
What about the following Label disadventage:
Let's assume we have a graph consisting of car nodes and driver nodes.
the car nodes have a manufacturer-name label, e.g. "FORD".
Now, the question is: If I have a driver-id, and I want to fetch the manufacturer-name of the car he drives, it appears that what I will do is:
I would select the driver node from the graph, and then get the car node (in which he drives), but then - how can I get the "FORD" label as a string? (Assuming I don't know it's a Ford, and it might be 100 other company names).
If it's not possible, is it correct to say that in such case (where I need to be able to do that) the manufacturer-name should be a property?
All depends on the scope and mandate for the Db. Since a single driver can drive many cars (i.e. Manufacture) or a single car (i.e. Manufacture) can be driven by many drivers. It is safe to create separate nodes for both cars and divers and add properties where needed.
Moreover, in future, you might need to add more properties.