Scrum does not mandate the use of user stories; they are simply a useful agile practice. While the Product Owner could certainly use technical specifications instead of user stories to build the Product Backlog, most of your other process problems stem from a failure to embrace effective Scrum and agile practices.
Various Problems with Your Process
Your Scrum appears to be broken in a wide variety of ways, including:
- Your specifications lack an explicit point of view or value proposition.
- Your backlog items aren't being tied to Sprint Goals.
- Your Backlog Grooming process is either missing altogether or failing to create story spikes for the Product Backlog.
- Your Sprint Planning process is not adequately decomposing Product Backlog items into Sprint Backlog items.
- Your team is not properly including uncertainty about backlog items in its Sprint Planning estimates.
- Your team is not respecting the fundamentals of time-boxing or the integrity of the Sprint.
While Scrum is not always the right fit for every project, in this case it would be more accurate to say that Scrum isn't working because the team isn't really doing Scrum. Your question about user stories is only a small part of the larger process issues facing your team.
Why Agile Programmers Embrace User Stories
Technical specifications are a fundamentally broken way to communicate requirements. Requirements that are unmoored from a point of view don't provide any useful guidance for developers. Using your posted examples:
- Rewrite object cache. Why? What's the objective? Who receives the benefit? Who can provide clarification about the task? If this is tied to a non-functional requirement, what project goal does this address?
- Implement system logging. Why? Who's going to read the logs? What information do the logs need to contain? How will you know if the log format or log data are useful?
From a developer's perspective, not being able to answer these sorts of questions leads to exactly the sort of process problems you describe. That's what user stories do: they provide much-needed context and act as placeholders for additional conversations with stakeholders or end users about specific features.
You shouldn't use user stories because you think it's a framework requirement, or because it's a widely-accepted agile practice. Instead, you should work on creating and using them effectively because it makes programming tasks easier and the programming profession more fun. Your mileage may vary, of course.