I agree with @shiling, that you have decide what you're trying to accomplish overall. There is nothing wrong with RSpec and your current use to validate your base Rails infrastructure [ yes, I took a quick peak ].
I can only guess that you're looking to expand your functional testing coverage with UI based testing [ not truly E2E testing ]. Its definitely helpful for when you're changing foundational underlining code that shouldn't impact the user experience or UI components. However, as its been pointed out the intentions of the UI testing needs to be defined.
Now I can't give you insight into Cypress vs TestCafe, but I can give you my thoughts or insights for adopting GUI automation from a QE perspective.
If the UI test creation audience is the developers and not a QE, then keep the test framework & language close to the daily used language(s) (easier adoption)
Be definitive about separating automated test focus [unit tests, API tests & functional UI tests].
UI test should validate/assert behavior and/or data interactions.
Treat UI tests like a unit test. They should run independently. They should not rely on another tests success or failure.
When UI tests are independent, all necessary data to complete a test must be seeded, created or found in the test environment [ key for a successful CI/CD/CT environment ].
True UI E2E tests should only be built in special cases and run during integration or before a release.
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.