These types of programming are different, but not in the way you describe. It's not the cliche of CRUD LOB vs. "Cool things", but of making apps targeted at the end user vs. creating a shared infrastructure (whether it is a library or a cloud service), and there are many levels down that rabbit hole.
But that being said, Unless you are working for a very conventional small or midsize business with no plans of rapid growth (and businesses of these rarely employ large teams that need leadership anyway), it's never going to be "just CRUD" or just slapping a client GUI in front o a database backend". With large datasets or many users you have to plan your storage and query patterns for scalability, when precision is crucial you have to design for consistency when a real-time response is required you need to reduce latency and when business requirements change often you need to design for flexibility, when your company has multiple clients you need to design a good API, and so on. In most cases you must balance between several requirements, and I haven't even gotten to security yet, which is a too often neglected requirement for almost every system out there. I also didn't touch all the peripheral requirements for having automated tests (and designing for testability), designing a CI pipeline and educating junior devs about revision control workflows and DevOps practices.
Handling all of that doesn't require the same technical skills required for writing kernel code, a ray tracing engine or a database engine (all of them different skills in their own respect), but to be able to design a good system and give guidance to junior developers you definitely need more than 2-3 years of experience.
Yes, many companies choose to ignore what I've just said, and hire low-level programmers anyway, and often put an MBA (who did some formulas in Excel back then) to (micro-)manage them. Of course the products they turn out are buggy, hard to upgrade, fall down to pieces under the smallest hint of load, end up requiring expensive hardware, have gaping security holes and all-in-all cost their failings end up costing the business dearly.
This blasé approach to group 1 development is very common in the so-called "enterprise world", but that's just because the organizational elite over there (as opposed to most of Silicon Valley) is not even tangentially technical. That's understandable: take a CS-driven company like Google or an engineer-driven company like Facebook, and you'll get the mirror image. But there's no cold truth about programming skill not being a big deal here. Group 1 development is at the very least as demanding a skill as plumbing.