But is there more to it than that?
You can just take a variable and use it rather than think about what type it may have at the moment of needing it.
That's a great recipe for code that nobody understands or can maintain. It may work when you hack up little scripts, but when a project becomes more complex, "just using it rather than thinking about it" stops working.
And potentially you can change its type later on.
Yes. And have the code break in 50 different places that all implicitly assume that it's a certain type and which are pretty much impossible to find before they cause a runtime error (which may happen months after the change for rarely executed code paths). That's OK if you have a comprehensive suite of automated tests. If not, good luck...
Thinking about the type of variables is something you cannot avoid if you want to be a professional programmer instead of a dabbling amateur, whether or not your programming language forces you to do it everywhere.
Dynamically typed programming languages only spare you the work of doing it explicitly everywhere, which can be tedious and lead to unnecessary complexity of its own (Java Generics wildcards, anyone?).
Statically typed programming languages have the great advantage of allowing tools to be very smart. The compiler tells you about type errors. Change a type somewhere and it will tell you about those 50 places that have to change. Want to know all places where method
execute of class A is called, and not bother with the 2000 other places the word appears in other classes, comments and documents? In a statically typed language, your IDE can do that.
The disadvantage is that type systems can get very complex when they try to cover every corner case, and force you to deal with the complexity even though those corner cases that necessitate it may never occur in your application.