Dmitry,

The times I have used a custom ASPX/ASHX page is because I didn't want all the extra overhead of DNN when loading those pages.  An example with the ASHX is when I want to dynamically load an image based on some sort of criteria such as in an eCommerce module, loading the image based on an imageID (from the database).  Or perhaps I want to expose export functionality to export a CSV, PDF, or otherwise based on data in the module.  I certainly don't want the entire page lifecycle loading up with that... all I want is to export that document and move on.

The ASPX pages are a little more complicated when or why I would choose them.  My day job is working for a financial institution and sometimes our financial backend needs to request data from the intranet or other applications I've written; web-services would be an excellent shoe-in in these instances but the programmers working on that end don't really understand how all that works -- they can post out to a web-page and then wait for data to come back in a "special" way.  So I accomodate them; my ASPX pages are for the sole purpose of accepting information from the financial package and then posting it back out so the financial software can accept and parse my data.

Another example of using an ASPX page is a company calendar I wrote which shows all the different events and allows employees to sign up for events.  The signup isn't merely clicking it... sometimes they need to fill out additional information, choose a timeslot, etc; it would be a "heavy" process to load that all into a hidden panel and then show it when necessary so I opt to "popup" the information in a dialog and load it on a separate ASPX page. Again what it comes down to is that I don't want all the extra DNN lifecycle loading with it... I only want the bare minimum to keep the page light and load fast.

You ask if DNN itself is limited in any way and in my experience I'd have to say no.  I have never found a task that I couldn't accomplish with it.  I've built a lot of HUGE custom modules for internal consumption at my day job; our intranet runs DNN and I have built that thing up to the point where our employees use it extensively.  Our custom user directory alone gets 15k hits per week.

Lastly, you wonder if you should package the ASPX up with a module and place a link.  That is what I have done, I find it easier to package it that way so I know where the file is.  You could just as easily drop it into the root of your DNN folder and then drop your DLL into the bin (or if it is VB.NET you can simply allow it to dynamically compile with the app upon request; you can likewise drop it into another folder if a C# file and then tell the web.config that said folder contains C# code).  I prefer to precompile all my code, keeps it fast and ensures I catch all compile-time errors before somebody else does.

Skins; you can reuse a skin on your ASPX page by inheriting from DotNetNuke.Framework.PageBase... I can't remember the rest of the steps, but by inheriting your ASPX page from that class you gain access to the DNN framework.  The problem here is that the second you do this you'll have to dynamically add your controls to the appropriate panes instead of just having them simply inside your ASPX page normally.  I'd probably convert my skin to a master page if you had a ton of ASPX pages you wanted to handle this way but I hope from above you see that the ASPX page should only be used in pretty special circumstances.

Hope that was informative and helps set you up.  Let me know if I can help out more in the future.