It's possible to move 50 nodes at once. If you do this, the move workflow is called 50 times, as the following code implies:

ezpublish_legacy/kernel/content/action.php

    // move selected nodes, this should probably be inside a transaction
    foreach( $nodeToMoveList as $nodeToMove )
    {
        if ( eZOperationHandler::operationIsAvailable( 'content_move' ) )
        {
            $operationResult = eZOperationHandler::execute( 'content',
                                                            'move', array( 'node_id'            => $nodeToMove['node_id'],
                                                                           'object_id'          => $nodeToMove['object_id'],
                                                                           'new_parent_node_id' => $selectedNodeID ),
                                                            null,
                                                            true );
        }
        else
        {
            eZContentOperationCollection::moveNode( $nodeToMove['node_id'], $nodeToMove['object_id'], $selectedNodeID );
        }
    }

Moreover, the search index (solr) is also called 50 times. All in all you might run into a timeout if you do this at the backend. Performance-wise, it would be useful to have a "bulk move operation", so that there would be no need to do all the same operations 50 times in a row.

In fact, a patch has been devised in the past to deal with this. The main idea of the patch was:

If you have 50 nodes to move then you are only able to move them to 1 parent. So put the 50 node_id's into an array and only call the operation once (instead of 50 times).

So, the workflow events are only called once, the cache clearing is only called once, solr is only called once.

For reference, the patch in question ('002_batch-move-v4.diff') was provided in support ticket https://project.issues.ez.no/10465, and I included that patch in this issue, so that it can be used as the foundation for the bulk move feature.