BDD is suitable for all levels of testing, Gherkin not so much. Writing unit-tests with the overhead of Gherkin (e.g. English feature files, regular expressions and functions to execute the tests) is extra work, but work that does not have the value of conversation as only developers read them.
Describing your tests from a behaviour stand-point is very good for all level tests. Even for the unit-tests, because only testing the implementation details leads to change-detector tests, which will harm refactorability on the long run.
If you want to let non-technical/-developer roles add or change test-cases then BDD in a readable format seems to make sense. If you want to let these people also add unit-test cases I would have a look at FitNesse where inputs and expected outputs can be described in a wiki format.
For the higher level tests Cucumber-like frameworks make more sense as the tests are more user-oriented. This way you can discuss requirements with the users before they are built.
Personally I gave up on Gherkin as the developers see it as extra work, the business does not read them as they like to focus only on the high-level. The testers tend to love it, but it adds extra complexity that is not worth it if the business and the developers are not in on it.