whether the notion that sprints/iterations in agile development should always be back-to-back
Yes. A Sprint is timeboxed, and the next sprint starts right after the previous one's timebox ends. This provides the cadence and rhythm of a Scrum sprint.
with only a review and planning meeting to separate them from each other
Reviews and Retrospectives are held at the end of a sprint. Sprint Planning is done at the beginning of a Sprint. These Scrum Events bookend the actual Sprint, as opposed to occurring 'in-between' Sprints.
There is no rest. We sprint, and then we sprint again, and then it continues on, supposedly forever. When we "slow down" to manage tech debt, we do it in a "Sprint".
Paying off technical debt is part of the Stories to be completed within the Sprint. Ideally, technical debt should not accrue very much if we do most of the XP practices (i.e.: test first, refactor mercilessly).
Of course in the real world, debt does accrue. A good strategy is to allot some time for refactoring while User Stories are being decomposed into subtasks. For example, a User Story from the Product Backlog is written such that the value to the business is stated, but as we decompose it into constituent tasks, we correctly estimate that existing code must be changed for our new feature to be integrated in. At the end of the Sprint, developers get their value in better code, and business gets their value in working software.
Can't we do a few sprints to get a core feature/product delivered and then do no sprints until we are really ready to take on the next big piece?
I would invite the development team to review their coding practices, if there may be some improvements so that quality can be built-in. Perhaps pair programming? Code reviews? Senior members taking more time to mentor others? Test-Driven-Design to minimize bugs and to make sure they are not over-designing/gold-plating?
How about the Sprint Retrospectives? Are team problems being raised and attempts at improvement being tried? Are Daily Scrum standups devolving into old-school Project Manager "status reports"? Does the Product Owner respect the Development team's decision regarding the capacity of Stories to be done in a Sprint?
There are a lot of possible ways Scrum can be tweaked to optimize performance. As long as the team keeps to Scrum's core pillars of Transparency (people are upfront with what's happening), Inspection (both work and the work process is being evaluated fairly but realistically), and Adaptation (doing something to improve a situation), each iteration should sort itself out eventually to a better one.
Further reading from the official Scrum Guide