Technical stories

Yes.   In my experience, it is a direct result of the component-based, team-specialization model that organizations continue to employ while struggling with Scrum.

It is difficult to have a Scrum Team identify with the business-value factor of a PBI when they're so silo-ed in their approach.   Work still looks like a list of to-do's.

A couple suggestions that I've had success with that may help your situation:

1)  Any item created on the team's Product Backlog needs to be customer-facing.   This may help with being able to identify with business value/benefit, and may help move the conversation (and story design) away from an assembly-line, horizontally-sliced approach towards more vertically-sliced, broader business-need discussion.

2)  When a story is proposed, some key questions to ask are "Why, What, How, and Who?"   Why is this story being proposed?   What problem is it intending to resolve?   How does this benefit the business?   Who benefits from it?  

Very often, the "technical" stories you're experiencing would be tasks on a more business-centric story.

A few more questions to ask: Why does the Product Owner feel that user stories don't provide value?   Why does your team feel that Scrum is how they should work?   Why is there organizational resistance to forming feature teams?   What does your team's Definition of Done look like, if they're not being asked to create a cross-functional product increment (per the Scrum Guide)?

Good luck!

Who will be accountable for the value provided by the component team, i.e. the team which is implementing those so-called "technical stories"?

They are a component team, working at the UI layer of our stack, building a component which is shared across our product, affecting lots of different users.

Who will be the users of the features provided by the component and why can the PBI not be defined as user stories from the perspective of those users?

It's a pity that your team and even the PO does not see they are providing value.

I encountered those questions and viewpoints many many times, since I entered the agile community. I was very surprised at first. For me that's a very old and very traditional (and technical) view - I expect to see more modern views in agile communities. For in my past traditional work environment we had a very different notion of "customer" (aka user): A customer of a team is not only the "end user", but could be also internal customers - everyone that uses or is touched by the product . So it's more like the notion "stakeholder" (which is also a wider notion than only sponsor or requirements originator).

I recommend to do a workshop to talk about the notion "customer": Who is the customer of the team? Who is using the product the team is developing? This includes all the other teams using the component. So they are the users and they are looking for business benefit (aka value) in the product (component). Of course the end user is also a customer - and I agree that it's often very hard to formulate the benefit such an end user. So there might be a story that references the end user now and then, but don't stick to that too close or too often - don't let the study book notion of a customer narrow your sight. Look for the customers/users of the component!

The recommended workshop might help the team to start changing their view of the team and their view of providing value. They are not "only component team", but they are providing benefit for their customers! They should be looking for ways to improve such benefit. And this will help to improve the benefit of the overall product for the end user, too.