Even in a context of a single page application, the idea of caching holds.
Consider that you may be using JavaScript libraries that are publicly available (jQuery, for instance). It's likely other people's webapps (single page or multiple) also use it. If you use the same public URI, we may be able to cache that.
But wait, maybe you have the jQuery version stashed on your own servers, to off-load others, or because you can serve a better connection, or whatever. Now you can inline, right? Yes, provided that you have no other webapps that also use that library, or that it is highly unlikely for users to use more than one of those webapps.
Things that you write specifically for that single page of yours, that have no relevance to other pages or applications, yes, you can safely inline. For the rest, I'd say: think broader than the page.
There are trade-offs to the approach you suggest. It's not inherently bad, and there are clear upsides (fewer HTTP requests), and there are downsides (caching issues). I'd call it optimisation; if you have good, verifiable evidence that inlining will resolve an issue, then that's a good reason to do it.
You may find the comments on the accepted answer for "Why not embed styles/scripts in HTML instead of linking?" relevant, especially:
If you are doing a single page app style site then where the vast majority of the code was specific to one page then it might make some sense still?
If the page is visited only once, yes. If visited multiple times, all the embedded stuff gets transmitted multiple times instead of just once and cached.
Do not forget the effects of a CDN or local caching at the isp. My request for the javascript for google likely never reaches google even if I have a cache miss locally because another person who uses the same isp will have already caused the isp to cache the data.
There is also the potential issue of parsing, though that's more a caveat than a breaking issue.
