The thing is, you have to find a small analyze between function that return elements which takes arguments and functional component that returns elements which takes props.

Consider the below example :

 //here is the difference, when you use function, function takes arguments as it is.

  const  UpdateIcons = (products) => { 

  // if you use this as component props will be like products props will return the products object again, here you have to use {products} destructuring or products.propducts["One"]

  //like this const  UpdateIcons = ({products}) => { 

    if((products["One"]  === "A") && (products["Two"] === "B") && (products["Three"] === "C") ) {
      return <p>Conditional</p>
    }
    return <p>Show Always</p>
}

   class MyIssue extends Component {
     render() {
       const { products } = this.props;
        return ( 
          <div>
           {UpdateIcons(products)}  
           {/*passing arguments here products will be {"One": "A", "Two": "B"}*/}

           <UpdateIcons products={products}   /> 
           {/* passing props , props will be same as products */}
      </div>)
      }
    }

    class App extends Component {
      constructor() {
        super();
            this.state = {
                products: {
                   "One": "A",
                   "Two": "B",
                  "Three": "C"
                }
            };
     }

     render() {
        return <MyIssue products={this.state.products} />
     }
   }

working demo

The useRef hook is not just for DOM refs, but can store any mutable value you like.

Example

function FunctionalBar(props) {
  const [foo] = useState(new Animated.Value(0));
  const _foo = useRef(0);

  function showFoo() {
    let anim = Animated.timing(foo, { toValue: 1, duration: 1000, useNativeDriver: true });
    anim.start(() => console.log(_foo.current));
  }

  useEffect(() => {
    function _onChangeFoo({ value }) {
      _foo.current = value;
    }

    foo.addListener(_onChangeFoo);
    showFoo();
    return () => foo.removeListener(_onChangeFoo);
  }, []);

  return <View />;
}

It seems you are wanting to compute a myTitle value based on some prop or context value being passed to the component. Storing passed props/context values in local state is generally considered anti-pattern in React. Compute the myTitle value and pass it along to the child component.

const MyComponent = () => {
  const myTitle = someContextApiObj.value === "XYZ" ? "XYZ" : "ABC";

  return <ChildComponent myTitle={myTitle} />;
};

If the myTitle value is an expensive calculation or you just want to provide a stable reference to children, use the useMemo hook to provide this.

useMemo

import { useMemo } from 'react';

const MyComponent = () => {
  const myTitle = useMemo(() => {
    return someContextApiObj.value === "XYZ" ? "XYZ" : "ABC";
  }, [someContextApiObj]);

  return <ChildComponent myTitle={myTitle} />;
};

I had the same concerns as well when I first saw the proposal, but this was addressed in the React Docs Hooks Proposal FAQ:

Are Hooks slow because of creating functions in render?

No. In modern browsers, the raw performance of closures compared to classes doesn’t differ significantly except in extreme scenarios.

My takeaway is that although you have additional overhead now in the repeated declarations per render, you have additional wins elsewhere:

• Hooks avoid a lot of the overhead that classes require, like the cost of creating class instances and binding event handlers in the constructor.

• Idiomatic code using Hooks doesn’t need the deep component tree nesting that is prevalent in codebases that use higher-order components, render props, and context. With smaller component trees, React has less work to do.

Overall the benefits might be more than the downsides which makes hooks worth using.

The reason is if you useState it re-renders the view. Variables by themselves only change bits in memory and the state of your app can get out of sync with the view.

Compare this examples:

function Foo() {
    const [a, setA] = useState(0);
    return <div onClick={() => setA(a + 1)}>{a}</div>;
}

function Foo() {
    let a = 0;
    return <div onClick={() => a = a + 1}>{a}</div>;
}

In both cases a changes on click but only when using useState the view correctly shows a's current value.

You could have it be a state variable, but that wouldn't make much sense since the state is meant to hold variables that relate to the current state of the UI. Also, state variables are meant to trigger a re-render if they are updated (with setState()).

Neither of these would make much sense for a timer ID to be stored in the state. In other words, it's not a state variable because:

1. The timerID doesn't express the representation of the UI in any way.
2. Updating the timerID shouldn't trigger a re-render.

The official docs actually mention this:

The state contains data specific to this component that may change over time. [...] If you don't use it in render(), it shouldn't be in the state. For example, you can put timer IDs directly on the instance.