I am looking into this at the moment too and my understanding so far is that a 'context' is essentially some encrypted form of the object, or information that the TPM (and only the TPM) can use to re-derive that object back in the protected hardware space of the TPM.

The need for them seems to stem from the fact that the TPM has an extremely minimal amount of working RAM/memory on it, and so any operation you want to do with the TPM that involves certain objects will probably require those objects to be re-loaded back into the TPM at the point in time you want to do the operation. For example, it does not seem uncommon for TPMs to only support having three or so objects actually loaded at any one point in time.

Storing whole unencrypted keys in files outside the TPM would defeat some of the purpose of the TPM because then cryptographic operations with those keys could be performed outside the TPM, beyond its ability to enforce any authentication policies on the operations such that they can only be performed with e.g. the right password. So this seems to be why these object context files themselves contain encrypted data that only the TPM can decrypt.

I'm still not 100% sure if I've got this all right - will update this answer if I am able to get to any clearer of a conclusion here.

Some references:

Part 1 of the TPM 2.0 Library Specification defines a context as follows:

4.17 context

collection of data that provides qualifying information about a data object to differentiate it from others of the same type or to differentiate one version of a data object from another

The 'A Practical Guide to TPM 2.0' Book (free download, CC BY-NC license) says the following:

chapter 18, pg 294

Because the TPM has limited internal memory, objects, sessions, and sequences need to be dynamically swapped in and out of memory. As an example, the reference implementation of a TPM 2.0 implemented by the Microsoft simulator only allows room for three object slots. An object slot is internal TPM memory for an object or sequence. There are also three session slots.

pg 295:

TPM2_ContextSave saves the context of a transient entity and returns the entity’s context. The returned context is encrypted and integrity protected. This is done in a manner that only allows the context to be loaded on the exact same TPM that saved it; a saved context can’t be loaded into a different TPM.

I am looking into this at the moment too and my understanding so far is that a 'context' is essentially some encrypted form of the object, or information that the TPM (and only the TPM) can use to re-derive that object back in the protected hardware space of the TPM.

The need for them seems to stem from the fact that the TPM has an extremely minimal amount of working RAM/memory on it, and so any operation you want to do with the TPM that involves certain objects will probably require those objects to be re-loaded back into the TPM at the point in time you want to do the operation. For example, it does not seem uncommon for TPMs to only support having only three or so objects actually loaded at any one point in time.

Storing whole unencrypted keys in files outside the TPM would defeat some of the purpose of the TPM because then cryptographic operations with those keys could be performed outside the TPM, beyond its ability to enforce any authentication policies on the operations such that they can only be performed with e.g. the right password. So this seems to be why these object context files themselves contain encrypted data that only the TPM can decrypt.

It is also worth noting that these saved contexts seem to only be usable within the one powered lifetime of the TPM running - i.e. they become unusable after a power reset. This is because they are for 'nonpersistent entities' that live in volatile RAM on the TPM. Objects can only reliably be used across power resets if stored in the non-volatile RAM with tpm2_evictcontrol (which also includes a facility for producing 'serialised persistent handles' which may be able to be used between resets and volatile RAM storage/clearing, not 100% sure on this).

I'm still not 100% sure if I've got this all right - will update this answer if I am able to get to any clearer of a conclusion here.

Some references:

Part 1 of the TPM 2.0 Library Specification defines a context as follows:

4.17 context

collection of data that provides qualifying information about a data object to differentiate it from others of the same type or to differentiate one version of a data object from another

The 'A Practical Guide to TPM 2.0' Book (free download, CC BY-NC license) says the following:

chapter 18, pg 294

Because the TPM has limited internal memory, objects, sessions, and sequences need to be dynamically swapped in and out of memory. As an example, the reference implementation of a TPM 2.0 implemented by the Microsoft simulator only allows room for three object slots. An object slot is internal TPM memory for an object or sequence. There are also three session slots.

pg 295:

TPM2_ContextSave saves the context of a transient entity and returns the entity’s context. The returned context is encrypted and integrity protected. This is done in a manner that only allows the context to be loaded on the exact same TPM that saved it; a saved context can’t be loaded into a different TPM.

And back in chapter 8 on pg 100:

A nonpersistent entity never persists through power cycles. (To be precise, it doesn’t persist through what the specification refers to as a TPM Reset (a reboot). It does persist through a TPM Restart (resume from hibernate) or TPM Resume (resume from sleep).) Although a nonpersistent entity can be saved (see TPM2_ContextSave), a TPM cryptographic mechanism prevents the saved context from being loaded after a power cycle, thus enforcing volatility.