Yes, this is a great use of Alfresco.
One approach would be to set-up a simple document promotion or publishing process via rules. You can have a content rule that automatically moves or copies a checked-in document into a "doc library space", where docs promoted into that space from one or more collaboration spaces could represent known, good docs that can be surfaced on the intranet. This "promotion" can be conditional based on some metadata value set by the user at check-in time (user marks the item "FINAL", for example) and can kick-off advanced workflow, or - better - yet, a simple approval process.
In a web project, you can create a form that allows a publisher to specify which documents to fetch from the doc library, how many items to render in that list, sort order, metadata attribute display (show summary, show author, etc.), and more. That form data (XML) can have a template applied to it which generates a dynamic web page (a JSP, for example). That JSP can either (a) directly query the repo based on the parameters supplied by the publisher to generate a list of docs in the library or (b) and better still, have a callout to a web script which generates the doc list based on the supplied parameters - meaning you're coding in Javascript and writing Freemarker templates rather than making API calls.
Now, that web script should be generic. You might want to allow a publisher (using a repeating element in a page form) to add multiple doc lists, and for each doc list specify a different set of docs from the doc library to return. This is where we'll be heading with web scripts - making them reusable web components that are business user configurable when adding to a page within our WCM system.
Let me know if you've any further question. But in short you are right: we can not only do this, but it is definitely a huge part of the value prop of having a combined ECM platform.
Kevin
PS Please note, when publishing in an Internet or extranet setting, it is
often preferrable for the doc promotion process to copy a
transformed rendition (PDF) of the doc to one or more web projects
(using our pre-built action when creating content rules). The
reason for this is that because the rendition is contained within
the web project, it is snapshoted along with the rest of the assets
and transactionally deployable to one or more systems that are
hosting your website outside your firewall or in your DMZ. For
intranets, this is less important, as it is often easiest (and their
are no or fewer security, firewall restrictions) to just serve docs
straight out of the document library.