Why use std::forward<T> instead of static_cast<T&&>

Scott Meyers says that std::forward and std::move are mainly for convenience. He even states that std::forward can be used to perform the functionality of both std::forward and std::move.
Some excerpts from "Effective Modern C++":

Item 23:Understand std::move and std::forward
...
The story for std::forward is similar to that for std::move, but whereas std::move unconditionally casts its argument to an rvalue, std::forward does it only under certain conditions. std::forward is a conditional cast. It casts to an rvalue only if its argument was initialized with an rvalue.
...
Given that both std::move and std::forward boil down to casts, the only difference being that std::move always casts, while std::forward only sometimes does, you might ask whether we can dispense with std::move and just use std::forward everywhere. From a purely technical perspective, the answer is yes: std::forward can do it all. std::move isn’t necessary. Of course, neither function is really necessary, because we could write casts everywhere, but I hope we agree that that would be, well, yucky.
...
std::move’s attractions are convenience, reduced likelihood of error, and greater clarity...

For those interested, comparison of std::forward<T> vs static_cast<T&&> in assembly (without any optimization) when called with lvalue and rvalue.

forward expresses the intent and it may be safer to use than static_cast: static_cast considers conversion but some dangerous and supposedly non-intentional conversions are detected with forward:

struct A{
   A(int);
   };

template<class Arg1,class Arg2>
Arg1&& f(Arg1&& a1,Arg2&& a2){
   return static_cast<Arg1&&>(a2); //  typing error: a1=>a2
   }

template<class Arg1,class Arg2>
Arg1&& g(Arg1&& a1,Arg2&& a2){
   return forward<Arg1>(a2); //  typing error: a1=>a2
   }

void test(const A a,int i){
   const A& x = f(a,i);//dangling reference
   const A& y = g(a,i);//compilation error
  }

_{Example of error message: compiler explorer link}

How applies this justification: Typically, the justification for this is that using a static_cast avoids an unnecessary template instantiation.

Is the compilation time more problematic than code maintainability? Should the coder even lose its time considering minimizing "unnecessary template instantiation" at every line in the code?

When a template is instantiated, its instantiation causes instantiations of template that are used in its definition and declaration. So that, for example if you have a function as:

  template<class T> void foo(T i){
     foo_1(i),foo_2(i),foo_3(i);
     }

where foo_1,foo_2,foo_3 are templates, the instantiation of foo will cause 3 instantiations. Then recursively if those functions cause the instantiation of other 3 template functions, you could get 3*3=9 instantiations for example. So you can consider this chain of instantiation as a tree where a root function instantiation can cause thousands of instantiations as an exponentially growing ripple effect. On the other hand a function like forward is a leaf in this instantiation tree. So avoiding its instantiation may only avoid 1 instantiation.

So, the best way to avoid template instantiation explosion is to use dynamic polymorphism for "root" classes and type of argument of "root" functions and then use static polymorphism only for time critical functions that are virtually upper in this instantiation tree.

So, in my opinion using static_cast in place forward to avoid instantiations is a lost of time compared to the benefit of using a more expressive (and safer) code. Template instantiation explosion is more efficiently managed at code architecture level.

Here are my 2.5, not so technical cents for this: the fact that today std::forward is indeed just a plain old static_cast<T&&> does not mean that tomorrow it also will be implemented in exactly the same way. I think the committee needed something to reflect the desired behaviour of what std::forward achieves today hence, the forward which does not forward anything anywhere came into existence.

With having the required behaviour and expectations formalized under the umbrella of std::forward, just theoretically speaking, noone impedes a future implementer to provide the std::forward as not the static_cast<T&&> but something specific his own implementation, without actually taking into consideration static_cast<T&&> because the only fact that matters is the correct usage and behaviour of std::forward.