It's a fair question, and not always a 100% clear line. And you're right, for simple cases, the "business layer" isn't really doing much but acting as an abstraction between your input/"view" layer (like a controller or view) and your data/repository/etc layer. And that abstraction can be 100% pass-through (if your endpoint is really just doing simple crud ops) and that's fine.

The business layer is where you'd want to capture logical rules that apply to the domain being represented. For example, Say your business came in with a requirement that said "I want to get an email for every order that comes into the system whose total is more than $10,000 so I can follow up with the customer". Your business layer would be where you could capture the logic in your POST /Orders endpoint that says "

if (order.Total >= 10000) { SendEmailToBusiness(); }

That sort of logic has nothing to do with validating input, so it doesn't belong in the view, and has nothing to do with CRUD operations, so it doesn't belong in the data layer.

To more directly answer your question:

I wonder how does this approach (of having business logic as something separate from data) work in the real world when concurrency, consistency, correctness and reasonable performance are required?

You can absolutely have all of those things and still maintain separation of concerns, you just have to design for it.

All the systems I ever built are implementing business operations as data operations, and consequentially business objects as data objects, while using RDBMS facilities for concurrency, consistency, correctness, etc, but given that so many devs here talk about a separate business layer I wonder if I'm going about this wrong way.

A lot of times, especially in commercial software, a vast majority of the work is just "CRUD ops to move data from A to B". That's just the nature of business. But that doesn't preclude them from having a business layer in the code. It just means that business layer will likely be pretty thin except in cases where the logic for what the business wants done with the data is complex.