I've seen a strange use-case today: someone I know simply can't create and configure Custom Fields effectively (they lack permissions), to the point where instead they are opting to just create dozens of Sub-Tasks per Issue, each one representing a field.
In this configuration, a Sub-Task Summary becomes the Field Name and the Value is the Sub-Tasks' Description.
So instead of a Custom Field with name "my-field" and value entered: "the-value", they will create a Sub-Task in the Task type Issue with a Summary of "my-field" and a Description of "the-value" (and then go and do this for several more fields they can't properly setup Custom Fields for).
I didn't know how to respond because they've achieved their goal of instantly creating "custom" fields and saved themselves from the headache of having their system admin approve and configure actual Custom Fields (which apparently is a very difficult and slow process). Also, from an Automation perspective (why I posted here), this doesn't seem to prevent querying these issues since JQL can search by Sub-Task Summary as well.
But are there any possible repercussions to this work around? I couldn't find any issues related to this other than a very old post that said too many Sub-Tasks could cause performance concerns. Is the performance concern still valid and are there any other concerns with respect to Automation (querying accessing issues)?
https://community.atlassian.com/t5/Jira-questions/What-s-the-maximum-number-of-subtask-s-per-issue/qaq-p/413470