I had a long discussion about dot notation with LiveCode's CTO, Mark Waddingham. The result was an appreciation I've gained for his earnest stewardship of the LiveCode language. He feels dot notation is not a good fit for the unique flavor of LiveCode, which would not only break from a leaning toward more natural-language expressions where practical, but also dot notation establishes expectations of OOP conventions not supported in the language.
So yes, it means using "of" instead of ".", but over the course of a code base allows for readable code that's almost self-commenting.
In the example you provided above, the difference in typing is 10 characters. Since the long form is 74 characters, the shorter example saves about 13.5%. That might seem like a lot when extrapolated across a code base, but it's limited to statements that set properties so in practice it would likely result in a keystroke savings of maybe in the range of 3-8%, depending on the nature of the code.
When assessing verbosity, it's helpful to consider the code base as a whole, rather than a single statement. While many LiveCode statements are longer than their counterparts in other languages, in many (most?) cases you'll find yourself typing far fewer statements for an equivalent task.
So if the seeming brevity of dot notation might save us as much as 8% across the code base, LiveCode's conveniences like GUI controls as inherent language elements, automatic type coercion and memory management, and others may likely result in a savings well in excess of 20-40%, depending on what the code does and what it's being compared to.
In C++ or Java it's common to see code blocks that are much longer, given the necessity of declaring variable types, manually managing memory, etc. Even in popular scripting languages like Python and JavaScript, being core languages only with no inherent facilities for GUI objects, they need to work with external subsystems to provide an interface (wxWidgets or the browser DOM, respectively), and the code to use those GUI objects is not always (or even often) sparse.
In short, yes, when we isolate single statements LC can appear verbose for some operations.
But when we look at keystrokes-per-application, LiveCode's not bad at all, and often compares favorably.
Moreover, there's the nature of the each programming language itself. Python is white-space-sensitive, which Python programmers enjoy but drives some newcomers crazy. Bash is sparse to an almost insane degree, with a unique way of working quite unlike any other lanugage. JavaScript is typed, but not strictly, and OOP, but not purely. And LiveCode favors readability where practical.
Every language has its own unique strengths and weaknesses. The reason our world has so many is so everyone can enjoy the one that best fits their own set of priorities, and indeed new ones are invented every year for that reason.
If brevity were the only priority we'd all be using bash. Or Perl, famously referred to as the "write-only language.
I'm not sure it would create a shorter learning curve, since you would most likely as a new person use it more like a crutch instead of going to find what you need to know, but it sure would save time depending on implementation (seen both good and bad on that one, for instance preferred Delphi 5,6 to VB 5,6 auto-complete). I would guess (although I haven't tried to work it out) that you could write a script that would collect the type and name of objects added into an array, and then insert a drop index of possible values into the editor, but at the point I am now it is above my pay grade 
