Let me first answer your main question, "Do one day sprints make sense". In general: no. The need for a one day sprint are often a sign of things out of control. I've seen agile coaches practice one day sprints in operations environments and in crisis teams, but never for software development teams who also need to deliver features.
Scrum applies Focus to ensure that the value delivered in a sprint can be maximized. Interruptions and massive scope changes, as well as loads of defects and incidents cause the Focus to be lost and will drastically lower productivity, the ability to estimate and to create a short term plan that helps you achieve your sprint goal.
Often the notion of one day sprints are caused by problems in previous sprints, Product Backlog Items declared done, receiving massive feedback from clients when shown weeks later. That's a sign of the customer not being involved often and early. It's also often a sign of an absent product owner or a proxy product owner.
It may be that the nature of the work is just too unpredictable, in Operations environments or customer support departments, you often see that the flow of incoming work is constant, yet the ability to predict the work coming in is absent. In these cases Kanban or another flow optimization technique may be better suited than Scrum. It's not valuable to spend half a day planning, knowing it's for naught. You will loose some of the benefits of continuous learning, cadence and predictability which Scrum offers, and will need to ensure you either keep doing some of the Scrum events or do something else instead for your Sprint review an Retrospective.
It sounds like the nature of your work should not be the above. You can cater for some incoming additional work using a small buffer or some up-front discussion with the product owner about which PBI's carry more value than others, so you know how to deprioritize some work over other. A strong product owner can also help in these cases, weighing which issues are truly worth interrupting the team for and which ones need to be pushed back to the client. Each incident gives them a short burst of value, but it tends to lower the long term value due to the fact that you're unable to deliver new items in a sustainable way
It also sounds like your Support team could be a better buffer for the Development team. Would it be possible to rotate some Devteam members through the support team for a couple of weeks/months, pair-programming with the support team? That would allow the support team to pick up more knowledge of the products you're building. That way they can solve more issues themselves.
It also sounds like the customer isn't always happy with the work delivered, or has new insights based on what they see, can they be involved earlier and more often than you're doing now?
You may need shortish sprints, say one week, due to the fact that part of your work is unpredictable, but with a strong product owner and the ability to deliver new work mid-sprint (by not waiting for acceptance at the end of the sprint), you will be able to either postpone some of the work to the start of the next sprint, or to keep a buffer to deliver the highest priority work this sprint.
Just a final note: Your team is the owner of the Sprint Backlog and is allowed to ignore or refuse requests to change the sprint backlog. They're required to when the Sprint Goal is jeopardized. Only when the current sprint goal is no longer valid or valuable, is the Product Owner allowed to cancel a sprint.
