You touch on a lot of things in your post. I'd like to try to help with some general classifications that might help you understand what you will get with the different technologies.
BDD(Behavior Driven Development):
This is less of a technology and more of a "way" of testing. Similar to TDD by name and acronym but very different in approach. TDD is the idea that you write a set of test before you start to code, and the code you write should be done when it passes those tests. Most commonly done by developers as part of the development process. A very important distinction is that TDD DOES test the implementation. BDD does not. You want to negate the implementation and only test the BEHAVIOR, or the user facing functionality of the application. That doesn't mean it is always an end user. You could test a backend with BDD style tests. The important thing is that with BDD you care about the output and should NOT be testing the implementation.
Cypress vs Cucumber:
These are two different things. Cypress CAN use Cucumber(here is a link of a package that helps you do just that) By default it uses Mocha, yet another BDD syntax you can use to organize your tests... Important take away: Cucumber is a syntax that has your code referenced by GIVEN, WHEN, or THENS that represent Preconditions?setup, the action under test, and the expected result. The cool thing about Cucumber is your code is called up by these GIVEN/WHEN/THEN "steps". Why that is important is someone reading the test, they can be sure that if the GWT step is the same step in a different tests, both would use the same under lying code... Pretty cool, huh? Cucumber is a way of writing highly readable test and allowing others to read or write test and now that the underlying code will be the same. You can write new tests by just reorganizing the GWTs! You can also use RegEx expressions to allow for test case parameterization. You can even connect those parameters to a data table! Here is an EXAMPLE
How is Cypress.IO different than Selenium?
This could be an entire article on it's own. I will present the most important difference for me. The architecture... Here is a link to the diagram from this post. What is significant about that? The app under test runs INSIDE of a container controlled by cypress. That allows a tester to stub request(inward data) and spy or mock data(outward data). This goes beyond the obvious network traffic. You can even stub functions of the browser. Cypress doesn't support multi-tab testing. No biggie, you stub the new window(or tab) action, and when the app under test fires that, it simply opens the URL in the same window. This is nothing short of amazing as you can do this with almost any function or traffic. It isn't easy though if you don't have decent programming knowledge. Devs can help.
What cypress is not
UPDATE: Cross-browser testing now has limited support with Cypress4.0. covering Firefox and MS Edge(>=79).
Fun fact: MS Edge version numbers jumped from 44.xx to 79.xx when they
changed to the chromium engine so that their version numbers would
sync with chrome...
Cross-browser testing is not supported at the moment. You can only test in chrome.
You mentioned backend, ui, and e2e testing above
Cypress is typically used to test frontend or UI. It can be used for integration testing, and possibly unit testing(might be better to use something like jest instead). It also has the ability to fire REST request using the cy.request command. You could write some API testing with and some javascript, but a tool like postman would be better for a comprehensive testing suite for an API.
Selenium could be use similarly for UI, API and e2e testing. You can't use it for lower level integration testing or unit testing. They have libraries that can help you with REST(API) testing, but you'd want to use an API testing tool for a large suite. Both cypress and Selenium support API testing to allow for sending calls to speed up test(logging in to the backend and obtaining a token that gets added to local storage instead of hitting the UI and having it handle the token setup for you).
Sounds like you are still pretty new to automated testing. It is tough at first but a great field. I would research some of the stuff I mentioned above in greater detail. Feel free to ask for more clarification. Happy Testing!!!