i think the library's approach to DI is pretty neat (and meets a team where they are which is worth a lot), but i think you're running into an issue where people are saying that instead of working around the realities of your codebase, team and testing needs, you should have done something like this.

  const useCountdownValue = initialTime => {
    const [time, setTime] = React.useState(initialTime);
    React.useEffect(() => {
      const interval = setInterval(() => {
        setTime(t => t - 1);
        if (t === 1) clearInterval(interval);
      }, 1000);
  
      return () => clearInterval(interval)
    }, []);
    return time;
  }

  const Countdown = ({time}: {time: number}) => {
    return time > 0 ? <>Time left {time}</> : <>Done</>
  }
  
  const ActualCountdownInContextSomewhere = () => {
    const remainingSeconds = useCountdownValue(60)
    return <>
      <Countdown time={remainingSeconds} />
    </>
  }

i'll say, i have never written a test for a hook or looked into what's needed to actually do that, but i suspect you don't need cypress or webdriver to test something like this has the correct output

  <Countdown time={-1} />
  <Countdown time={0} />
  <Countdown time={1} />

or likewise you can probably use sinon or jest's fake timers to test the hook (however it is hooks are tested without triggering that error about not calling hooks outside of a function component, i guess you need to mock React.useState?).

but like, whatever works for your team! i think it's fair to argue for either direction, but neither is zero-cost unless you have buy-in for one direction vs another from your coworkers, which honestly is all that matters especially if you have to eat lunch with them occasionally.