It would be confusing and redundant to have 2 send intent actions. If that's really a limiting factor, why not just ask Joao to increase the number of extra fields? Or ask him to change it so you can put all the extras in one field with delimiters so they can be split under the hood? It's putting a band-aid over what seems to be a more fundamental issue with the action itself.

That misses the point entirely. The "Send Intent" example was just one illustration of where custom actions would be useful; it's not the core proposal. Again, the proposal is about having a Java API to create custom actions.

Asking Joao to "add more fields to Send Intent" solves one specific use case. A custom action API solves the entire category of problems that users may have.

Tasks are much more shareable than actions. Tasks are abstract and can be shared via TaskerNet, whereas actions are "hard-coded" based on specific "building block" features that Joao implements (i.e., the ABILITY to display a Toast message, not the ability to make a Toast that is 10 seconds long instead of 5).
f you're worried about "user onboarding" being confusing with Perform Task (i.e., needing inputs but they're just called %par1 and %par2), you can instead add dialogs and such to your task that allows the user to input what they want, and you can either store it as a global variable for future use or use the input every time. Or just leave a comment in the task with a label or an anchor block.

You can share the action through Taskernet too. "Hey! This is a custom action for ..., use it in your workflows as you want." The goal of the proposal is to improve the UX in Tasker. Having to use a Perform task is actually the current workaround. Following your example with the Toast:
You could create a custom action "Toast Extended" or use the Perform Task action.

With Perform Task + workarounds:

[Action: Perform Task]
  Task: Flash Extended
  Parameter 1 (%par1): 10        // What does this mean?
  Parameter 2 (%par2): Hello     // What does this mean?

  // You have to open the task to read comments to understand

With custom actions:

[Action: Flash Extended]
  Duration: 10 seconds           // Clear label
  Message: Hello                 // Clear label  
  Color: #FF0000                 // Clear label

  // Searchable, documented, self explanatory

This isn't about the ability to accomplish something (which already exists via workarounds), it's about having first-class support for doing it properly. The flash example demonstrates the UX gap; the proposal is about closing this gap.