Look, not all of those things are bad but jesus fucking christ, what happened to exercising restraint and good judgement with introducing dependencies in to your projects? Dependencies are a LIABILITY and for something to be introduced it has to be worth it, not just provide some minor syntactical convenience (like Butter Knife, etc.)
I have always been doubtful of its benefits but after giving it a fair chance, that's still the case :/
It removes a tiny bit of code, that does not seem that helpful to me. I still have to add the id in the java code, and I would have to count to know how many characters I save that way. Not many. And now I need to worry about how the bk magic happens to be sure to do not leak that way.
I am used to databinding, where I initially had the same reaction .. but after some use it allows you to gain a lot of time with two ways binding and binding adapters while staying at a sane level of abstraction IMO (it just writes the boilerplate code for you) .
Don't you use Retrofit for your network API code?
Android has a bit of a different architecture history : at first the framework team has built it as modular components (IIRC you were not even supposed to be able to subclass Application) with no recommandation on how to architect your app code outside of that.
It lead to MVC with all the business logic in massive activities .. at least for most companies.
We now have the same jungle of really abstracted patterns with some of them actively fighting against the framework by rewriting it. To be fair, parts of the framework like fragments have been a disappointment (and again to be fair Google is hard working at addressing this).
I just want the minimum amount of abstraction that gives me the advantages I want (separation of concerns, testability) and not rewrite everything from scratch.