On the contrary, creating a potentially shippable product is the very definition of agile, both the lowercase and uppercase varieties.
Working in cycles or iterations but not producing anything shippable at the end of it is essentially what most people in the business call water-scrum-fall. It's a kind of cargo cult, following the motions and rituals of some Agile methodology without actually being, well, agile.
If "agile" does not mean "ability to ship at (almost) any time", then what good is it? If you say that your team is agile, you are communicating to the business that you are able to respond to changes to requirements or to the business environment in general. But if you can't actually ship anything, then how are you "responding" to that change? If you can't ship, then all you are really telling the business is "we won't complain too loudly when you change your mind", which is a lie of omission when they think they're hearing "we can deliver whatever you need, whenever you need it".
I can't find the link anymore, but Microsoft recently did a case study on this. There was a team that converted to some sort of cycle/increment-based Agile methodology and relied on frequent product demos to show progress, but when management said "OK, we're ready, release it" it turned out that the team wasn't actually "done" with any of the work they'd demoed. There were hundreds of critical bugs that had to be fixed, data migration that needed to be performed, validation and security requirements, and so on and so forth. And when all was said and done, it took something like 6 more months to actually get it ready to ship.
My team had a similar experience last year, during which I was the lead and learned my lesson pretty well. Oh, I was obsessive about quality, and so we really were done according to our definition of done. But, as it turned out, a ton of mostly-unpredictable faults happened when we finally hit the staging environment, and it took almost two more months before we were able to go from "done" to "shipped". The business was fairly understanding, considering the size and importance of the product, but it was stressful as hell for those of us essentially getting no "real" work done for two months, and during those two months the business could potentially have been bringing in revenue on a perhaps less complete, less polished, but still shippable product.
The idea of bringing pain forward is at the heart of Continuous Integration. CI says that if integration is hard and expensive, you should do it today, not tomorrow or next week, because the total theoretical amount of effort required to integrate is the same whether you do it as a series of 10-minute interruptions or one 10-day death march. Not only that, but in practice, it actually costs more to integrate later, because individual contributors/teams are able to diverge from each other much more (intentionally or unintentionally) between monthly integrations than they would be between daily integrations, and the higher number of risky or potentially destructive changes means a higher percentage of time spent on just debugging. So, smart teams use CI, and not just in the sense of having a build server but in the sense of forcing everyone to either commit directly to the mainline or integrate with it every day, and deploy to a shared environment every day (or every hour, or whatever).
But CI is a beginning, not an end. CI is for the dev team; it doesn't help the business at all. Just because you got something working in CI doesn't mean it's shippable. And all of the problems with delayed integration that CI aims to solve have technical or business counterparts when production releases are delayed for too long. There's a risk that the dev team has diverged very far from the product requirements, or that the CI infrastructure/environment has diverged very far from production. The only way to minimize that risk is to ship often, which is what "continuous delivery" practices aim to solve, by extending the CI pipeline to include end-to-end test automation, infrastructure automation, and release automation.
You don't have to automate everything; plenty of teams scrape by with manual QA and deployments. But they maybe manage bi-monthly releases, or monthly if they're lucky. That's nowhere near as agile as some companies.
When I hear the word agile, I think of companies like Amazon, Facebook, or Google. It's easy to be agile when your product is only 500 lines of code and you don't have to do much testing, but the real test is when you're managing sprawling products with millions of lines of code and hundreds or thousands of developers. Facebook releases twice a day. Google sometimes releases the same product a few times in the same week. Amazon is on record as releasing something every 11.6 seconds (2011 statistic), although I think Amazon is a bit of a special case because they aren't actually releasing the same thing each time, their architecture is massively service-oriented and distributed.
Simply put, if you can't basically push a button to release shortly after the end of an iteration, then you aren't agile. Being able to respond to changes in or from the business means that you can ship. The business doesn't care that you can start working on something else at the beginning of each iteration, they care if you can deliver what you worked on at the end of it.
N.B. Things like "writing tests" and "polishing the UI design" should happen during the iteration, not at the end of it! Most agile teams have a "definition of done" and those things are very, very high on the list of priorities. I don't even consider that part of shipping, that's fundamental product work that is very dangerous to defer. You're not even close to being agile if those things aren't done at the end of a sprint/iteration/whatever. If you're having trouble completing those things on time, you may need to revisit your team structure - it's a common problem in manufacturing-style teams where developers, designers, testers, and infrastructure are all treated as different teams and separated by literal or metaphorical walls. This is a terrible model but some companies still use it because there's too much bureaucracy or simply too much stubbornness to reorganize.