I've actually heard more people be opinionated that the front-end code is more important to test than back-end code. The idea is that if the back breaks, the front breaks. If the front breaks, the back could still be passing. Front tests breaking will tell you if the front or back is broken, which at least gives a better picture of the application.
My workplace shoots for 70% unit test coverage (yes, coverage is a BS metric... it's a large company) of all code. Front, back, whatever. And every feature gets automated end-to-end tests as well.
My E2E stack is Protractor and Jasmine, since all the front ends at work are Angular. I haven't had any issues with the tooling other than some quirks around how every extra package seems to make it more likely that Protractor is going to have timing or intermittent issues. Vanilla Angular plays fine with it, though, and Jasmine is 👌
And by quirks, I mean running supertest tests from the Protractor run, sending MySQL queries during beforeAlls, and other things Protractor totally wasn't meant to do. But also the Angular app having 3rd party libraries which work manually but make Protractor give up.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.