Does high quality software really use plain names like `Employee` to describe domain objects?

I don't think you'll find consensus for this naming convention. I've worked in code bases that use names without suffixes, and code bases that use suffixes, and even prefixes.

I don't know if I fully understand the premise of your question, but if I venture a guess, the "plain name" repeated everywhere would get confusing if the only difference in each layer of the application is the namespace. This is due to programming languages allowing you to write the class name without the namespace and specifying imports at the top of a file (although compiled languages would force you to include the namespace if a naming conflict happens).

The majority of projects I've worked on use the plain name for the domain model (e.g. "Employee") and then add prefixes or suffixes to different representations of the same concept in different layers. For example, the Employee domain model might have an EmployeeRepository in the data access layer, a CreateEmployeeRequest in a web API or REST endpoint, and an EmployeeViewModel in a GUI application. The list goes on (I've heard this naming convention called Smurf Naming, and related question in this community).

Really, you've hit on the main strategy with naming things: establish a convention in a project and stick to it. Don't be surprised if you need to document this naming convention, no matter what it is. Humans are notoriously inconsistent with naming things.

The important thing is to choose names that aren't surprising (for your project) which facilitate communication between teammates using terms that are derived from your users' terminology so those same teammates can also communicate with your users.

Yes, its better to call the model Employee and use that throughout the application.

Reuse of the same model class simplifies code, encourages correct encapsulation and allows caching.

Any method or function that needs Employee data will accept the same Employee model.

In some case you might find it expedient yo make duplicate classes, for example your ORM package might want to use decorator attributes to aid serialisation, but you don't want to add these to your model. In this case you can use a name space and access modifiers like private and internal to hide them.

In your particular example I would suggest the following refactor to remove the dupe classes.

QuestJournalModel -> QuestJournal
QuestJournalClientModel -> Delete
QuestJournalViewModel -> JournalScreenViewModel

Here the JournalScreenViewModel contains all the info needed for the Screen/Page/Scene

JournalScreenViewModel {
  QuestJournal qj;
  //extra client journal info
  int playerId
  Vector2 mapLocation
  .. etc
}

A different Screen/Page can reuse the same Model you already have in memory ie. Maybe the main screen has the "Active Quest" displayed at the top

MainVM {
   QuestJournal qj;
   int Score
   ...
   public string ActiveQuest { get => return ql.Quests.Last().Name; }

If you have a single class whose instance contain the complete data for an employee, then you can call this class Employee. Which is probably a lot better than EmployeeInstanceMakerFactory or something similar.

So good quality software can but not necessarily must contain short names for essential classes.

Does high quality software really use plain names like Employee to describe domain objects?

That's far from being about quality software, it is about the accuracy the domain specific language (DSL) of an application is describing the reality the application models. If for the application it is relevant to have model, client model, view model 'cause model abstracts the database, client model abstracts the information sent over the network and view model abstract displayed information it improves it's readability that could be completely unrelated to its quality.

I don't think there's a consensus. The question is how much context you want your developers to have to pay attention to when making sense of their code. It's almost never a black and white decision.

I've worked in environments where we ran into trouble because a name like Employee was used not only in a large project, but across multiple projects which were attempting to unify into one larger ecosystem. I've also worked on projects in Java where we were forbidden from using "import" directives. I could not use Math.sin(x), but had to write java.lang.Math.sin(x) because the prevailing opinion was that more explicit phrasings like that helped readability, and there was a fear that someone might get confused if two modules imported different Math classes with different sin functions in them.