@bart that's what I saw in most of the discussions about integration and functional tests... Most of the time I read people describing them with different words but testing the same thing :) The difference is probably about the methodology and not about what you test...
In fact the definition of the tests and what the test suites does are not matching completely. There's no strict definitions of them and people are just defining their own strategies by looking at the nature of their project...
For example in my projects I do two types of tests, unit tests and selenium tests. I don't want to call selenium tests as a user acceptance tests beacuse it's smt. in between user acceptance, user interface and functional/integration tests:
User acceptance tests are not about testing the user interface, it's more about testing the user stories. (Google given-when-then stories). It's to test if the software is doing what it's designed to do... Unlike the functional and unit tests it has nothing to do with the technical details of the code and software design...
User interface tests are to test if there's smt. wrong with the user interface and selenium is used for that too that's why it's usually referred as a UA test too. The problem with that is, they're very very fragile...
Functional/integration tests are as defined above... With codeception you can test with browser and also check the database if the data entered in the browser is actually written in the database. Two birds with one stone, might sound good at the beginning but things can get messy easily.
Unit tests will make your code better designed, others will make you catch those nasty bugs... The primary benefit you'll get from the unit tests is the increase in the code quality because to write testable code the developer is forced to design code in smaller units.
As I said, everyone has their own way of organizing their tests...
Obviously, testing increases the initial cost but pays back in time.
So, if you're working on a long term project, yeah test everyting, it'll pay back...
Otherwise you should find a good balance between what to test or not and how to test...
Just keep in mind that unit tests are the cheapest, UI tests are the most expensive.
(See test pyramid)