By 'the standard' do you mean POSIX? Or has that been added to a C standard?

Either way, in general I'd agree this is an excess of pedantry and I don't really see an issue with using _t for types if that works for you.

I wasn't sure, I just checked.

POSIX reserves everything ending in _t. C99 and later reserve identifiers starting with "int" or "uint" and ending in "_t".

Source: https://en.cppreference.com/w/c/language/identifier

For those wondering: that phrase has to be read as “C99 and later reserve identifiers ((starting with "int" or "uint") and ending in "_t")”, not as “C99 and later reserve identifiers starting with "int" or "uint" and identifiers ending in "_t"”

It’s not as if a program with a variable called interest_rate or ford_model_t would be nonconforming according to the standard.

While this is true, I don't see either a reason to use _t in your code. Since it's your code, you don't have the problem for which the _t suffix was introduced, that is to avoid conflicts that can break other people code. You don't either get any benefit of using the _t suffix, since it's obvious if something is a type or not, especially nowadays (just look at the syntax coloring). You don't even need the _t to distinguish for example between a struct, enum or union definition and it's relative typedef:

    typedef struct MyStruct { ... } MyStruct;

is perfectly valid, and in my opinion better than:

    typedef struct MyStruct_s { ... } MyStruct_t;

Where the suffix _s and _t doesn't add anything useful but only complicate the code for nothing.