Personally I would strongly recommend against transactional replication. It works 95% of the time, but the 5% of the time that it is broken, it is just an unbelievable hassle to deal with. In the environment I work in now, virtually every problem we have has been created as a bi-product of using transactional replications, some of the problems technical in nature, while others are a product of workarounds to deal with some of the constraints created by replication, primarily by developers and report writers.
Depending on your organization, you may also have problems keeping the environment as under control as you would like to with three distinct groups with different interests in the SQL environment being able to call some of the shots, according to their interests only. When it comes to replications, being able to saying "no" to certain requests is of paramount importance, but once you add one, I have experience it has usually been like a drug to report writers who want more and more and they just grow like cancer.
Does the reporting data really all need to be done in real time?
If it doesn't need to be live I would use stored procedures or SSIS to copy data from the source to a reporting database, then run that on a schedule.
I really despise named instances, so I would recommend against stacking them from that point, but would also be pretty leery about stacking three application facing instances on one server. The performance expectation of end users in an application is for fast reads and writes and when you stack up more than one database instance SQL has very little ability to intelligently control how the resources are shared. You can set a limit on memory, but its pretty difficult to limit disk i/o and CPU usage.
If you wanted to run three instances on one box, I'd virtualize three machines on it instead and then equally divide up the CPUs and memory between each guest, that way SQL isn't in charge of dividing resources, the hypervisor is. This adds a lot more complexity however.
Using an AAG can be a really good option for reporting if all your report writers are very good, and the data isn't that complex, but at least where I have been, that hasn't always been the case. The amount of babysitting needed could run away beyond your reach. Keeping a separate copy of reporting data to me is more about keeping the mess out of the live data. User expectation of reporting is also much lower than in the application. A user expects a report to take time to render, so a badly written report can get isolated away from the live data and then also not get complained about. I dont mind stacking SSRS, SSIS and the database instance on the reporting box either.