Firstly, proportion and usefulness are not the same thing. You use the doorknobs in your office many more times per year on average than your fire alarms. It doesn’t make the fire alarms less useful.
However, I don’t think of BDD being focused on functional and integration tests (although clearly that’s the intent of tools like Cucumber). While those sorts of tests can be part of that approach, I think the only essential part of BDD is ensuring that you have an objective, executable way to communicate behavior to stakeholders. Whether or not this is effective depends primarily on the people involved and how they best communicate. Which tools will be most effective is merely a function of those people and what they value.
I’ve worked with teams where we used JUnit tests as executable documentation, and it worked great. I’ve also worked with teams that (in addition to a unit testing library) used less programmer-y tools like Cucumber and EasyB to write tests that non-technical stakeholders could understand. In both cases, though, the overwhelming majority of tests were unit tests.