"id" is property that is translated into "name" of display object - but only if created in mxml - then it is converted into name in generated actionscript and your component will have "name" property that equals that "id" at runtime I think.
So if you set "id" via mxml - then it is translated (in the background by compiler) and you could access it directly via dot-notation in actionscript
But if you create component (UIComponent instance) at runtime with code - then "id" property is not directly translated into "name" property id DisplayObject - as there is no generated actionscript by compiler. So to avoid that do not use "id" when using actionscript - or re-assign id to name.
Also do not expect in #2 scenario that your "name" property will be available in dot-like notation (via brackets) in scope of given component - this could not necessairly be correct as in #1 scenario. Instead query via name given container (this could be very different control in mx/sparks), see below:
protected function addButtonHandler(event:MouseEvent):void
var btn:Button = new Button();
btn.label = "Button";
btn.id = "myButton"+getTimer();
btn.name = btn.id;
protected function buttonClickedHandler(event:MouseEvent):void
var btn:Button = event.target as Button;
var instance:Button = panel.contentGroup.getChildByName(btn.id) as Button;
trace(btn === instance);
(=== should yield true If I'm not wrong with this and "name" equals "id")
It is a very rare occurrence when I miss not being able to access an object (object property, really) using the ["name"] notation for objects created using actionscript.
In MXML the compiler is conveniently adding an attribute to the class with the same name as the id, so you can conveniently refer to it using the  notation. While we explicitly specify an application container to use, the MXML compiler creates a custom container which is a derivative of the base container and to that it adds properties for the children declared in MXML. I guess it also effectively calls "addElement" for us when the container is being constructed.
Your example assumes that using "addElement" to add the button to the application container is the same as declaring a variable (ie property ). It isn't, so there's no point in looking for an property of the name "as3Button" using the  notation, because it doesn't exist. The container is managing a collection of children in it's display list and that's not the same as being accessible as properties of the container.
Generally speaking, accessing properties using the ["name"] syntax isn't necessary.
[edit: you may wonder why "addElement" doesn't conveniently also add the "id" attribute to be an property of the container class. Unfortunately, it can't because the container class would need to be dynamic and it's not. A further complication would be that adding properties at runtime would invite naming clashes at runtime with associated mayhem. MXML can do this because the compiler generates the class and can trap name duplication at compile time.
Great question, BTW.
-last edit changed my "attributes" to be "properties" in line with Adobe's terminology]