Converting a graph database schema to a relational database schema
Starting at the end - if you have, say, 20 large tables of 10 millions rows each at 200 bytes per row that works out at just under 40GB.  Add twice as much for indexes and your entire database will fit into memory.  With sensibile indexes in place you really shouldn't worry too much about joining multiple tables.  Joins are what relational databases do, it's what their code is optimised for.  Don't be frightend of using your new software for its intended purpose.

Have you considered having different views for each specific use-case?  These will be easier to write and maintain.  The optimiser will likely do a better job, too, if it has fewer objects to consider in each view.

If you want an alternative, however, you could try modeling your data in a star schema, like a data warehouse. Task will take on the "fact" role and the others taking on the "dimension" roles.  You'll still have multiple joins but the opportunity for successive calculations on statistics producing silly answers is much reduced.

I would not try to shoehorn all the task-related values into one generic mega-table.  Think what the SQL would look like if you implemented task_relationship.  Does that really look better than joins on normalised tables?