This is to extend your own answer:
It appears that when “hierarchical” is set to true, each post behaves like a page. I am quoting here so I don’t really understand why it matters but changing this line remove the problem.
Here is what the codex says about the hierarchical parameter
hierarchical
(boolean) (optional) Whether the post type is hierarchical (e.g. page). Allows Parent to be specified. The ‘supports’ parameter should contain ‘page-attributes’ to show the parent select box on the editor page.
Default: false
Note: this parameter was planned for Pages. Be careful, when choosing it for your custom post type – if you are planning to have many entries (say – over 100), you will run into memory issue. With this parameter set to true WordPress will fetch all entries of that particular post type, together with all meta data, on each administration page load for your post type.
When a custom post type is set as hierarchichal, its behavior will be same as the build in post type page. Like pages, WordPress tries to build a tree to display the correct hierarchical tree with parent-child relationships in the back end. As you might have noticed, pages are not sorted by date in the back end, but by this parent-child relationship. This behavior you can easily see when visiting the Page page in back end.
This operation is very expensive as WordPress needs to get each page ( or post from a hierarchical post type ) on every page load and then look for that specific page’s/post’s parent and child pages to build a the correct tree for that specific page/post. If you have a large amount of pages or posts in your hierarchical custom post type, the query simply becomes to big and exceeds memory limits or times out, which leads to a fatal error, hence the WSOD.
Non-hierarchical post types like the build in post type post don’t have such a hierarchy as non-hierarchical post type posts can’t have child posts. Because there is no need to build a parent-child relationship tree (for obvious reasons), WordPress simply queries 20 (IIRC) posts per page ordered by date in the back end and displays them in contrast to hierarchical post type posts where WordPress has to query all posts at once, build a tree and then display only an x amount on a posts grouped according to their parent-child relationship. You can check this behavior in the Post page in the back end
So setting a custom post type to hierarchical tells WordPress that it should build a list/tree of posts grouped by their parent-child relationship and return those posts in that configuration. Setting a custom post type to non-hierarchical, you are telling WordPress to skip the whole relationship thing and to just return an x amount of posts per page ordered by post date
I hope this make a bit more sense to you why you should avoid making custom post types hierarchical, and why that is also stated in the codex