Split User Story estimation based on expertise

I'm curious to understand what benefit you might see from splitting the estimate this way?

In Scrum the whole point is to have a valuable, useful Increment every Sprint. Scrum doesn't use adjectives such as "partially", "almost", or "99.9%" Done. The product Increment is either Done or it isn't. 

If the Developers are sizing work with points, there is no partial credit. If the team is using velocity (optional in Scrum), those points would not be included, because velocity measure the amount of Product Backlog turned into a useful, valuable Increment. In fact if there is no new product Increment that meets the Definition of Done by the end of the Sprint, velocity is actually ZERO for that Sprint.

And the Developers size together as a team, there are no sub roles or sub teams in Scrum. This helps avoid handoffs and attitudes such as "not my job". All the Developers are accountable to meet the Sprint Goal and for the Sprint Backlog.

A Product Owner may want to know the size of Product Backlog items so he/she can make tradeoffs when ordering the Product Backlog. The wouldn't need to know the split either.

What do you think about splitting the estimation of a PBI between Dev effort and QA effort ?

I'd suggest that quality assurance is part of development, because it is necessary to craft a Done increment. The teamwork exhibited ought to reflect that truth.

My experience tells me that teams do this because they don't want to talk to each other about their differing skill sets. A programmer doesn't want to think about testing and a tester doesn't want to think about coding. 



This is a sign that the SM needs to help coach the team in cross-functionality. To understand why we work together to create a usable increment, and why our defintion of done is a team accountability. 



If teams split into 'dev' and 'test', they will never realize the value of Scrum.

As stated by others, this isn't a great idea and promotes team separation.

Another thing to consider, this is an estimate.  It's also an estimate based on effort or complexity that gets translated into story point that then gets applied as time - at least most folks do that.  I'm not saying this is a great approach but not unusual (use flow metrics instead).  Making the estimate with this much detail is just too much precision for what you know.

Ultimately, explain the issues and ask the team.  If they want to do something that's not optimal, try it and point out where it caused issues later.  Teams frequently learn better from soft failures than from being prevented from failing.