Both of your examples are completely unsound due to the as though.
You're forcing typescript to treat P/T as an object, but they are unbounded generics - meaning they can be non-objects.

const str = normalizeParams('foo');
// typeof str === 'foo'
// but at runtime
// str === {0: 'f', 1: 'o', 2: 'o'}

const num = normalizeParams(1);
// typeof num === 1
// but at runtime
// num === {}

const str = toKeys('foo');
// typeof str === string
// but at runtime
// str === {0: "0", 1: "1", 2: "2"}

const num = toKeys(1);
// typeof num === number
// but at runtime
// num === {}

Doing an as assertion really is unsafe here.
So the rule is really doing its job here by enforcing you don't write broken code.

Then what about adding extends object after the generic?

export function normalizeParams<P extends object>(params: P): P {
  return Object.entries(params).reduce((acc, [key, value]) => {
    value = typeof value === 'string' ? value.trim() : value;
    if (value) {
      acc[key as keyof P] = value;
    }
    return acc;
  }, {} as P);
}

Or, do you have any recommendation to handle these cases?

It's hard to say exactly - TS does treat generics kind of weirds in conjunction with empty object types.
This also all boils down to the object type being super hard to use at all.

THere's no way to write this function without using an as assertion from what I can tell.

Actually I respectly disagree with

This also all boils down to the object type being super hard to use at all.

It is very useful when you want a generic which must be an Object, not primitive nor Array, there is no alternative, the suggestions Record or unknown are not useful here. Of course this is another topic/rule question.

I actually just hit this in the typescript-eslint codebase 😄:

Simplified in our playground:

type ParsedOptions = Record<'a' | 'b', number>;

function parseOptions(): ParsedOptions {
  const result = ['a', 'b'].reduce((acc, k) => {
    acc[k] = k;
    return acc;
  }, {} as ParsedOptions);

  return result;
}

@bradzacher @JounQin what was the fix you had in mind? Adding an option to disable as casts?

Note that we're blocked from actually detecting unfixable reporting on my favorite TypeScript issue: microsoft/TypeScript#9879. 😢

Potential fixes:

1. don't error if you use both:

  const result = ['a', 'b'].reduce<ParsedOptions>((acc, k) => {
    acc[k] = k;
    return acc;
  }, {} as ParsedOptions);

2. don't error if the value being asserted is specifically {} (maybe behind an option)

The big problem you've got is this code is straight-up unsound though - it's not good code!

For example Josh your code has ParsedOptions typed Record<string, number> - yet your code does acc[k] = k - creating an object like Record<string, string>!!! TS doesn't complain about it at all thanks to the completely unsafe as.

There's also the problem of missing keys - your type specifies the object must have the keys 'a' | 'b', but if you were to modify your array to just be ['a'] then the code would typecheck fine and TS would accept result.b.toFixed() - but it would crash at runtime because b isn't ever defined!

.reduce is just a bad way to construct an object with known keys, sadly.
And there's not really a good option otherwise because like Object.fromEntries forcibly returns Record<string, T> - so you can't type the keys.

Now that v8 is released, per #7936, we can mark this issue as unblocked! 🚀