To be clear, I didn't (exactly) mean that the
author of a Flash animation has to think in terms of creating a "demoscene demo." I rather meant that the Flash abstract machine is designed to primarily
do the types of thing that demoscene demos do — i.e. to use vectors and gradient fills and clipping masks to achieve procedural visual effects. You could say that the SWF abstract machine has a "demoscene-alike Instruction Set Architecture." Most of the work of figuring out how to
achieve particular visual effects on that abstract machine, though, is domain-knowledge built into the "Flash compiler" of the authoring tool.
In my previous post, I emphasized Flash as a distribution format for a reason. While the authoring tools (and the .FLA project format) do work with clean abstractions of a timeline with keyframes and tweens (and objects with their own swappable animations that have their own sub-timelines), the .SWF export format bakes all that down into an imperative program for an abstract machine whose primitive opcodes involve defining and moving around (potentially texture-filled) vector objects on a canvas. Writing SWF bytecode directly, would be similar to programming against a retained-mode fixed-function graphics API like OpenGL — just without any 3D support. In other words, it would be like writing a demoscene demo.
Or, to put that another way: the core of the .SWF export format — before all the user programmability stuff was added — is basically a cousin of PostScript, but with a finishRenderAndWaitForNextFrame command, and the ability to set spline points' velocities. Which is very much unlike declarative vector formats like SVG. The closest comparison, I think, might be to the object-oriented vector display-lists used in vector-based arcade machines (see e.g. https://www.youtube.com/watch?v=smStEPSRKBs.)
But, in both the arcade games I mentioned, and in Flash, if you've achieved the effect you want and are now optimizing the final work for size and performance, doing so will mostly be a matter of modularity and reuse of small repeatable design elements. Having "mechanical sympathy" for what the Flash export format looks like, will push you toward certain authoring decisions, e.g. building complex scenes using many smaller primitive objects that each independently animate (or in later versions of Flash, are independent state-machines); creating objects that can be uniform and so constructed by cloning rather than redefinition (leading to a surprising number of 2D flash animations and later games that were built out of colored, untextured voxel boxes); etc. And — despite there being no actual programming involved in the Flash animation authoring case — this is still very much akin to the process of optimizing a demoscene demo.