If you could extract branch information from fabric tasks, and then merge the branch with associated deployment handled by GitLab CI, the workflow would be the simplest one.
For that reason maybe you could investigate more on your idea of parsing the task description, it could be a single point that solves the matter.
As a side note, if you want to disable CI for a specific commit you can just use [skip ci] or [ci skip] in the commit message and no pipeline is created for that specific case.
Features scheduled to be EE only are intended to be useful mainly for big organizations, you can find more information here: https://about.gitlab.com/about/#what-features-are-ee-only. The decision could be reverted, it depends also on feedback we receive from users, so feel free to discuss about that in the issue!
Thank you for sharing your thoughts: you're totally right, this feature has much interest by the community and is an high priority. By the way, this is also a very complex topic, as you need to provide great flexibility but at the same time the best UX. As usual, we move by iterating on the issue by little steps: first of all we need the basic building blocks, on top of them we can create the final feature. I mostly agree that test results and other "custom" information must be extracted automatically from logs, but we need to provide a generic model that can be easily adapted to everyone. Iterations on that brought us code coverage information, artifacts for failed jobs and browsing and online display of artifacts (ready to be released in 9.2), and we provide also workarounds, like using GitLab Pages, that can solve some scenario until the work is completed. I'd like also to mention our current effort in supporting CodeClimate (https://gitlab.com/gitlab-org/gitlab-ce/issues/4044). We will continue on this path (one of the issues you mentioned has the "direction" label), always open in receiving feedback and promoting collaboration at any level.