I'm sure that's not the case; instead, normally, it's an intentional distinction between the kind of things that "static types" are and the kind of things that "dynamic types" are. Merely because they share an informal descriptor doesn't make them comparable.
The unityped argument states only that any language admits a static type analysis regardless of whether it admits to it in polite company. From here gradual types are natural: just embed the unitype into a richer static type system.
If there's a dynamic type system (called a "tag" system sometimes to ensure distinctiveness) then that all lives after these types have run. It can be influenced by these types, but it is certainly more than merely syntactic/logical which gives it different correctness/behavior/UX properties.
I'm not sure what you're arguing. If you're trying to equate "dynamic types" with "(static) types" then I'd like to see how you're doing that. If you're trying to refute that "dynamic types" are "tags" then I'd like to hear your definition of "tags" which you feel inappropriately characterizes "dynamic types".
If you're arguing something like "both 'static types' and 'dynamic types' are elements of a larger class of things called 'types'" then I'd be happy to talk about that given a meaningful definition of this larger class "types".
Generally, however, I find that most definitions of this larger class of "types" are difficult to operationalize. Due to that, please re-read my responses and mentally impute "static types" wherever I say "types". I try to be explicit about this, and it is my general MO, so if any disagreement or misunderstanding still remains then I'd be happy to talk about that as well.
In the type community dynamic types are called tags, to contrast from static types which are thrown away after compile-time.
Types are not just "types", there exists myriads of interpretations and implementations. E.g. nominal vs structural, compile-time vs run-time, dynamic vs static, polynomial (HM) vs exponential (cartesian), sound vs unsound. Please get yourself accustomed to the type literature, or invent your own glossary, as perl usually does when it has no idea about prior art. In this case it has.
From the implementation POV tags are indices into types and used with primitives as tags, hence the name, reserved "bits", e.g. with 30bit intnums or the many free NaN tagging bits in doubles or normal class slots with multiword objects. They are carried along the lifetime of the variable, hence add critical run-time safety and inherent slowness.
The unityped argument states only that any language admits a static type analysis regardless of whether it admits to it in polite company. From here gradual types are natural: just embed the unitype into a richer static type system.
If there's a dynamic type system (called a "tag" system sometimes to ensure distinctiveness) then that all lives after these types have run. It can be influenced by these types, but it is certainly more than merely syntactic/logical which gives it different correctness/behavior/UX properties.