Using author to substitute for a publish server is not generally considered a viable alternative for any number of reasons:
- The moving of content from the author repository to the publish repository is how the system models published vs.unpublished content. Unlike other WCM systems that might use a status flag or some other indicator in the repository to indicate whether the content should be available AEM moves the content to the publish repository. If you were to put dispatcher in front of you author systemit would have no way to know whether or not content should be available to the public or not - essentially as soon as content was created or modified it would be immediately available on the web site. Obviously if you are using dispatcher it might take some time show up in cache but there really wouldn't be any way to have work in progress content remain unpublished for any period of time.
- Resource contention - writing to the repository as happens in an authoring system is a resource intensive process, and there are lots of processes that write to the repository in an author system - humans editing content, workflows executing, and any number of other processes. There really is no way to predict how these might impact the performance of your web site - if someone publishes a page that would typically flush all the HTML in you cache, increasing the load on the system. Not only might you web site be slower because authors were writing to the repository you authors might experience performance issues as well.This might seem unlikely if you have a lightly trafficked site, but with burst activity is could be surprisingly impactful to you authors.
- Author instances are configured by default to be authenticated systems. You can of course change security restrictions to allow anonymous access but that has the potential open up interesting holes in your security. It also means you have additional maintenance and potential upgrade path issues.
- You will have difficulty effectively following the security check lists for locking down your publish instances because many of the recommendations for hardening a publish instance would cause issues with authoring behavior.
- If you have even moderately complex authoring security it may conflict with the need for anonymous access (so if you have you deny access rules on content in order to control authoring access those rules may have to be overridden to allow anonymous access which would potential conflict with your authoring security rules.
That's a short list - there probably 10 other things I could list out that are less important but that you'd still need to solve for. Basically it's a really bad idea.
If you truely have a static site and you don't want a publish instance you could look at using the static publish agent to do a bake model for your web site instead of the dynamic model that is default approach. It's not particularly well documented, and it doesn't necessarily support all the features of the platform but for truly simple static sites it might work. You can find a reference to the agent here - http://docs.adobe.com/docs/en/cq/5-6-1/deploying/replication.html and a blog on how to use it here - http://www.wemblog.com/2012/02/how-to-use-static-agent-in-cq-wem.html.
