Pierre in the linked thread articulated the issue very well.

I am just trying to anticipate the workload per discipline so that I can know if a very specialized scrum team member is needed at 100%, or not at all for the next sprints.

_https://community.atlassian.com/t5/Jira-questions/Why-is-Team-field-in-sub-task-disabled/qaq-p/1870306_

Consider the case where a story has acceptance criteria which are front end user specific (for a web application) and there are changes in middleware or backend systems. Delivery of the story is dependent on subtasks that are undertaken by people who have specific skills, and their availability is shared across other stories and epics. Its not practical to break up the user acceptance criteria into separate stories for each of the skill areas required to deliver them. 

This is really needed on our side! So far I was not able to find a work around. At the moment we have User Stories and the testing team needs to create/adapt automated test cases based on that User Story. If I would use a "normal" task i would not be able to set the parent to the user story as they are on the same level. Adding the task to the epic would be somehow overshoot as the work actually belongs to the User Story. And leaving the parent blank is also not desirable. 

Bottom line this restriction from Atlassian is very annoying and the rational behind is for me not obvious.

Please fix this.

I will vouch for this. I have an Epic for a feature that's shared between teams, and then a Task on that Epic regarding different responsibilities during rollout, where I want to assign different teams to different Sub-tasks on that rollout Task. This is now impossible. Not all organisations are running Scrum, and even if they do, they will still encounter tasks that require some cross-team involvement. It will be difficult to get an overview of the rollout, if I need to create different Tasks for each team and then link them, and I should not use an Epic for rollout.