Your rule of thumbs is a good start. However, your focus seems to be distracted by implementation consideration rather than by the conceptual modelling.

Indeed, a one-to-one association means by definition that there is a one to one semantic relationship between the concepts that you model as classes:

UML specifications 2.5.1, section 11.5.3.1: An Association specifies a semantic relationship that can occur between typed instances.

The semantic relationship means a relationship between the substance of the associated concepts. I don't think that real one-to-one is not so frequent in the real world, but an example could be the relationship between a User (aka the person, with attributes such as name or birthdate), and a UserAccount (aka the representation of the user for authentication and communication in the system, e.g. login id and password or other authentication credentials).

Typically, you would model such a situation with a direct one-to-one association. If this association would have attributes on its own, you could make it an association class. But this does not change the one-to-one semantic realationship. It only enriches it, because an association is at the same time a fully fledged association and a fully fledge class., yet conceptually, you'd still reason on a one-to-one association:

UML spécifications 2.5.1, section 11.5.3.2: An AssociationClass is a declaration of an Association that has a set of Features of its own. An AssociationClass is both an Association and a Class, and preserves the static and dynamic semantics of both.

In other words: The association class does fundamentally change the implementation fo the model (you'd need an additional association table, with foreign keys identifying the related instances), but would absolutely not change the conceptual relationship: it's still the same concepts that are related in the same way, just with more or less details about this relationship.

Where things change, conceptually, is when there is not a real direct one-to-one semantic relationship between the associated classes, but that this relationship is only the consequence of other relationships.

when should it be replaced by an intermediate class?

When those attributes (such as date, role, status, or history) are best associated with the relation between those classes, rather than either of those classes.

Except, an intermediate class should be not replace their association. It should be associated with their association.

The reason why is because if you just replace the association with an intermediate class you end up creating a many to many relation between the classes.

By that, I mean, if you turn this:

into this:

It means (well nearly) the same as this:

Which isn't what you meant. What you meant was this:

Done this way the 1 to 1 relationship is still clear. And it's clear that the purchase association between can have multiple instances.

Why would a User have a 1 to 1 relationship with a Product? I don't know. These were just some handy pictures. Please forgive the semantic dissonance.

^{(Car --- Position at Time --- Steering wheel?)}

1 to 1 relationships are fairly rare. Be sure it's what you really need.

Due to ORMs there's a 1:1 relationship between relational models and UML models; I'm going to answer this in RDBMS terms. In part this is because you can rely on a rich literature of advice for properly normalizing data subject to business rules.

A convenient example use case would be a Student row, which optionally has a StudentProfile row containing large binary BLOBs such as identification photos. The business creates a student ID early in the matriculation process, and eventually gets around to producing profile data.

normalize

When is a true 1–to–1 relationship the correct modeling choice

It's correct when the real world relationship is 1 : 1. Consider racing day support software for racetrack announcers. We have a Ride, that might be a horse or racecar, and a Racer, that might be a jockey or driver. Each has physical attributes and a competition history. For the announcer's purposes there exists a 1 : 1 relationship right now. And then for tomorrow's race we may well publish a newly updated relationship.

In contrast a bookie making odds would want a fuller description of recent history, a superset: a many-to-many datestamped description of race pairings and outcomes.

The associative class / table you mentioned is the correct modeling choice when we have the very different situation of many-to-many. In a BCNF or 3NF setting, only an associative table can properly represent the many-to-many relationship. Each row lists the PK of both sides of the relationship.

the relationship may later need attributes (such as date, role, status, or history)

The history term sounds a little suspect, as it may imply multiple records in some other table for a growing history. Or perhaps it's simply a modified or created date. The first three, {date, role, status}, sound fine. They are all "small", so I would likely make them NULLable attributes of the primary record, such as Student.

I mentioned that student identification photos might be "large". In a column store database there tends to be little technical motivation to create a second table for a 1:1 relationship. In a row store database OTOH, segregating large columns, which are seldom queried / filtered on, into a separate table can be attractive. It lets a tablescan on the "narrow" table happen quickly with less I/O, leaving large BLOBs on disk rather than taking up space in the cache.

org chart

It is often the case that reading a firm's organization chart will help you understand the URL structure of their website, the module dependencies of their software projects, and the mapping of data entities to business activities.

To continue the previous example, perhaps the Admissions department is responsible for publishing the Student entity and allocating unique identifiers. And then campus Security uses those identifiers when publishing a StudentProfile entity.

Departments in an org chart will likely have different budget concerns and development schedules, different technical infrastructure, and different data governance. That can include working in a specific jurisdiction, data privacy rules, and data retention policies.

Any of those can be an argument for breaking up a "wide" entity with nullable attributes into multiple entities, each one corresponding to the relevant department or operational rules.