Which index shall I create in Postgres to speedup join of two big (several million rows) tables connected one-to-many?
It is quite reasonable for the planner to think that scanning 70,000,000 rows in sequential order is going to be faster than reading 310,075 in a random order.
If you tried disabling enable_seqscan and the query performance got worse, then it seems likely the planner is making the correct decision there.  Could you post an EXPLAIN (ANALYZE) of what happens in that case?

If it did a merge join on the index attributes_point_id_idx like you suggest, than for each row it returns it would have to jump to some random part of the attributes table to check that that row has not yet been deleted, to check the attribute_id to see if it is 0, and to fetch value so it can be returned.

If you make an index on (point_id, attribute_id, value) and you keep the table vacuumed, then it might choose to use an index only scan (as the input to the merge join) as now it can get all the data it needs from the index, no randomly ordered visit to the table is needed.

It could be a challenge keeping the attributes table adequately vacuumed.  The autovacuum system is only designed to reduce bloat.  Keeping index-only-scans efficient is not yet part of the autovacuum design.