You're right that there isn't a great mapping between the input boxes and the shape on screen.
But, I would guess that other UX priorities dominate the layout issue here because:
The x/y/rot/dimensions controls aren't used very often, so they don't need to be prominent (or even noticeable under regular use). They usually just need to be easily discoverable for the occasional situation where the user needs to fine-tune something or check dimensions.
Usually in drawing apps, you want to maximize canvas space and keep the toolspace reasonably small, to allow users to focus on the drawing. So you could lay out the dimension controls more intuitively (e.g. use a minimap or facsimile of the rectangle) but this would take up more space, which is not worth the space it costs for a control that is used far less often than, say, color palette, layers, pencil, etc.
So, even though it appears to violate good mapping design, it may actually be good UX design to scale down the dimensions controls so they are readily discoverable if users need them, but otherwise fit nicely onto the bottom part of a sidebar, or horizontally (as in photoshop) across a toolbar. For example:

This lacks the intuitiveness of a better mapped control, but could be totally appropriate because it occupies small space and draws minimal attention, which is perfectly proportional to its rare use.
I've consolidated the width/height into a 2 input boxes instead of 4, where the input is read-only if the rectangle can't be edited (I'm not sure why you had 2 separate sets for output and for input, but obviously you could leave it that way too).
BTW, if you really want to spend the space and time on a mapped control, the following one from Chrome's CSS browser is thoughtfully laid out for describing different dimensions for an HTML box.....it would be easily adapted to a mapped control for a PowerPoint rectangle or text box:
