Nope. The RectTransform is a Transform; any property that’s inherited from Transform, you can use from either and it’ll behave the same. You only really need to use the RectTransform if you need to access its properties that aren’t shared with Transform.
Let’s explain this by creating our own member variable that behaves the same way. I’m gonna use Vector3’s mostly because I’m used to explaining this concept with transform.position and I keep typing Vector3 anyway. 
public class YourThing : MonoBehaviour {
public Vector3 someVector = Vector3.zero;
}
// elsewhere (exhibit A)
YourThing someThing = GetComponent<YourThing>();
someThing.someVector.x = 0f;
This works. This is probably how you’re thinking transform.position and transform.rotation works, because someThing.someVector.x looks just like transform.position.x. However, despite the similar appearance, they’re not the same. I’ll get to that in a minute.
Now, let’s say you want to add some restrictions to the Vector3. You want to clamp its X position within a certain range, for example. You could make the variable private and add some functions to get its value and alter it:
public class YourThing : MonoBehaviour {
private Vector3 someVector = Vector3.zero;
public void SetVector(Vector3 newVector) {
someVector = newVector;
someVector.x = Mathf.Clamp(someVector.x, 0f, 10f);
}
public Vector3 GetVector() {
return someVector;
}
}
In computer science jargon, this is called encapsulation. You’re protecting the real value from being modified by other classes so that your class can rely that its value is treated a certain way. So now, you can hopefully see why this doesn’t work:
//exhibit B
someThing.GetVector().x = 0f;
In this case, I think this will not throw an error, but it will definitely not change someVector’s value. to do that, you have to do this:
Vector3 tempVector = someThing.GetVector();
tempVector.x = 0f;
someThing.SetVector(tempVector);
Now, writing GetVector and SetVector all the time gets annoying. So you can put these things into what’s called a property.
public class YourThing : MonoBehaviour {
private Vector3 secretSomeVector = Vector3.zero;
public Vector3 someVector {
get {
return secretSomeVector;
}
set {
secretSomeVector = value;
secretSomeVector.x = Mathf.Clamp(secretSomeVector.x, 0f, 10f);
}
}
}
//elsewhere
Vector3 tempVector = someThing.someVector;
tempVector.x = 0f;
someThing.someVector = tempVector;
//but not...
someThing.someVector.x = 5f;
It’s important to realize that, even though this last line looks identical to Exhibit A, when it’s compiled, it actually looks identical to Exhibit B. A property is a pair of functions that masquerade as a variable because it’s convenient. You get the benefits of encapsulation without needing to write SetVector and GetVector all the time. (It’s not always a pair; sometimes it’s only a getter function. This is usually the case for ‘read only’ variables.)
transform.position is a property because that value doesn’t really exist. It’s really stored as a local position (accessible by transform.localPosition, though I think that’s a property too), and when you access transform.position, it goes up the hierarchy and applies the positions, rotations, and scales of every parent transform. When you assign something to transform.position, it does the inverse, and assigns the modified value to its local position variable. (Efficiency note: because of all this math, transform.localPosition is always a better choice than transform.position unless you actually need its world space position. Some for .rotation and .localRotation.)
…anyway, like I said, transform.position is a property, which means that it’s really a getter and setter function that looks like a variable.
