are there any inherent problems or considerations with raising a ticket off of the back of a review, instead of failing it?
Not inherently. For example, the implementation of the current change may have unearthed a problem which was already there, but wasn't known/apparent until now. Failing the ticket would be unfair as you'd fail it for something unrelated to the actually described task.
in the review we discover a function
However, I surmise that the function here is something that was added by the current change. In this case, the ticket should be failed as the code did not pass the smell test.
Where would you draw the line, if not where you've already drawn it? You clearly don't think this code is sufficiently clean to stay in the codebase in its current form; so why would you then consider giving the ticket a pass?
Fail the code review, so that the ticket doesn't close in this sprint, and we take a little hit on morale, because we cannot pass off the ticket.
It seems to me like you're indirectly arguing that you are trying to give this ticket a pass to benefit team morale, rather than benefit the quality of the codebase.
If that is the case, then you've got your priorities mixed. The standard of clean code should not be altered simply because it makes the team happier. The correctness and cleanliness of code does not hinge on the team's mood.
The refactor is a small piece of work, and would get done in the next sprint (or even before it starts) as a tiny, half point story.
If the implementation of the original ticket caused the code smell, then it should be addressed in the original ticket. You should only be creating a new ticket if the code smell cannot be directly attributed to the original ticket (for example, a "straw that broke the camel's back" scenario).
The resources I can find and have read detail code reviews as 100% or nothing, usually, but I find that is usually not realistic.
Pass/fail is inherently a binary state, which is inherently all or nothing.
What you're referring to here, I think, is more that you interpret code reviews as requiring perfect code or otherwise failing it, and that is not the case.
The code shouldn't be immaculate, it should simply comply with the reasonable standard of cleanliness that your team/company employs. Adherence to that standard is a binary choice: it adheres (pass) or it doesn't (fail).
Based on your description of the issue, it's clear that you don't think that this adheres to the expected code standard, and thus it should not be passed for ulterior reasons such as team morale.
Otherwise the task fits the definition of done.
If "it gets the job done" were the best benchmark for code quality, then we wouldn't have had to invent the principle of clean code and good practice to begin with - the compiler and unit testing would already be our automated review process and you wouldn't need code reviews or style arguments.