I'd like to offer a different perspective. It is said that these terms come from mathematics, however, there the word argument(s) refers to the independent variable(s) of a function - the thing that can vary that is of direct interest to us given a certain problem that we want to understand or reason about. Take for example, this function:
f(x) = ax2 + bx + c
As written, this is a function of x, and in math-speak, x is the single argument. In other words, this formula indicates that you are interested in what happens as x varies (how the function behaves, what are its features, etc.). This is captured by the f(x) notation.
However, note that this designates many different functions of the same sort - what you'd call a family of functions (in this case, quadratic functions), as you can choose different values for a, b & c. Mathematicians call these parameters. The family of functions is said to be parameterized by a, b & c - and you get a concrete function by choosing some value for each parameter. One place where this comes up in application where it might make more sense to you as a programmer is in data analysis / data science, where you may want to fit a function to some data sample (i.e., to find a function that best describes a set of somewhat scattered data points, to identify a trend - e.g. occurrences of some medical condition across different age groups). The algorithms that do the fitting vary the parameters trying to minimize the error until some threshold value or a cutoff point is reached. The parameters may have certain technical meaning of their own, but the argument is what's considered the input to the function (the age, in the previous example). You could treat the function above as f(x, a, b, c), but the f(x) notation communicates that the idea is to think of it in a different way.
So, if your domain is mathematics (or statistics, physics, medicine, or some other field/subfield that utilizes this language), and if your users and domain experts think in these terms, you may choose to adopt the terminology to express these concepts (but in some way that's not confusing for the developers working on the project - that's where the notion of the ubiquitous language comes in).
Note however, that sometimes, these terms can have other meanings in different contexts within the same discipline (e.g. the term parameter is used in a different way when talking about parametric equations).
As a programmer, on the other hand, you would write the same function, f(x) = ax2 + bx + c, like so:
double someFunc(double x, double a, double b, double c)
or, in TypeScript:
function someFunc(x: number, a: number, b: number, c: number): number
There's no notational mechanism to distinguish the two roles, and as far as we (developers) are concerned, this is a function of four arguments. Besides, what we call a function is not necessarily the same concept as the mathematical function (we think in terms of procedures with possible side effects, they think in terms of maps between two sets), so the mathematical concepts of arguments and parameters don't necessarily translate.
Incorporating domain concepts here might look something like this:
function quadraticModel(x: number, parametrization: QuadraticParametrization): number
where instances of
QuadraticParametrization might be objects of interest in their own right, potentially used elsewhere in the application.
As you've noted, we tend to use "parameters" and "arguments" interchangeably in an informal setting. However, even in formal settings, there's no universal agreement. "Formal setting" just means that you have explicitly stated at some point in your discussion the definitions that you are going to use consistently throughout the discussion (or the document), because it's important for the purposes of the discussion to make the distinction. This distinction is not particularly necessary in most usual development activities, though (e.g., it might be more important if you are talking about, say, compilers). So you end up with all kinds of terms: formal argument, formal parameter, actual argument, actual parameter.
There's a convention where parameters are the variables as they appear in the function signature, while arguments are the concrete values that are passed in - but that's just a convention that may or may not be used in any given setting. And even within that convention, not everyone is in agreement when it comes to details (e.g., when you pass in something by reference (or a pointer), is the argument the memory address, or the referenced object; in different contexts, it may make more sense to choose one over the other). The Wikipedia article acknowledges this ambiguity, but is itself somewhat inconsistent, as some of the citations used to back certain claims aren't using the same terminology as that suggested by the context in which they appear).
So, that's the state of things - you either have to infer the meaning from context, or check if the definition is explicitly stated, and what's the scope within which it applies.
As for your own code, if you have to use such suffixes in your type names, agree with your team on the terminology (or pick some convention if you are the sole developer), and then use it consistently throughout the codebase. However, it might be hard to stay consistent over time (especially in a team setting). Perhaps a better alternative is to dig a bit deeper and find a suitable domain concept (a term that's out there, that people already use) that can serve as a name. You generally don't have to repeat the function name in the name of the parameter type (or in the name of related functions or types); the signature tells you what needs to be passed in. It's better if the type of the parameter carries some information about what that object represents conceptually, with the parameter name clarifying the role that it plays within the function or a dependent object.
On the other hand, you can't always find such concepts in the domain, e.g., when the structures formed by your objects/types/functions are more organizational in nature, and it's not clear or feasible to model things in a different way. In that case, there might be some value in sticking to a naming convention to help guide the developers working on the code (either other people or your future self).