[Codemonkey]

There's no difference between flash and fl, other than readability. Don't forget you might not be the only one getting to see the code. Maybe you'll open source your stuff one day... maybe you decide to attract a friend on the project. You never know and even for your future self that looks back at the code would probably benefit from logical sounding package names (just the same as with class names and property names).

Like Nutrox said, there's a convention that you would use your domain reversed; it makes sure your class name (formally, package plus class' name) is unique all over the world. It also makes sure all your applications are structured the same way and can be put together without problem. If for example you put them all together, you would have all your applications located at d:\mystuff\flash\projects\org\houseofcode\*. Suppose you would start to use version control (svn, cvs, clearcase what have you) you can put all your projects in there in a consistent way, without having to worry about variable classpaths and stuff. Consistency is the key to enlightenment.

Aside from conventions, it is wise to use logical names for packages. In the java world for examples, there are some widely accepted package names that appear in almost every web applications.
For example:
org.housofcode.webbap.service
org.housofcode.webbap.dao (interfaces for data retrieval)
org.housofcode.webbap.dao.impl (if there are a lot of dao implementations, otherwise dump 'em with the interfaces)
org.housofcode.webbap.application (model for example)
org.housofcode.webbap.controller
org.housofcode.webbap.database
org.housofcode.webbap.domain
org.housofcode.webbap.util
org.housofcode.webbap.value (value objects to expose domain objects to the views)
etc.

So, for larger applications it is not only a matter of readability, but also a matter of manageability.

Another thing, for advanced developers, packages can be very important in regards to exposing classes and interfaces to the public. For example, you can make classes package protected so that users outside that package cannot use that class. An example is that you do have a public interface, but keep the implementations hidden from the users by making those package protected.

Then there is the matter of teamworking on package units and determining the size of packages in general. I've written a post earlier about an article I found on this topic, which I thought was very interesting:
Packages and granularity