Yep, I see why you think it’s weird. At the moment, the technical complexity of implementing field-level permissions is too great, so it’s not on the radar.
However, for your example, I would imagine that the best way to implement this is to split a task across two dbs - one for sensitive fields, and one for general info. Each ‘task’ is then made up of a pair of linked entities (one from each db) and different users get different access (e.g. managers always see both, employees only see the general info).
You can use lookups if necessary, so that info from the general task entity is visible in the sensitive task entity, allowing the manager to see everything without having to navigate back and forth.
And depending on your flow, you can use automations to make things simple, e.g. create a ‘twin’ sensitive entity whenever a general entity is created, or vice versa.
It’s not ideal, and some features that we plan to deliver will no doubt make this sort of solution slightly more user-friendly, e.g. Editable Lookup Fields
We might even implement a semi-native solution for this kind of ‘twin’ entity solution so that the UI behaves a bit like field-level permissions even though it is in fact just paired dbs under the hood.