Hi DX.
There is no technical reason I can think of why an added cost point barrier on one of the TransitLines wouldn't work. Did you make sure to set the BarrierType field in Point Barriers to "Added Cost", or 2? If it's still set to 0, then it's functioning as a restriction barrier and ignoring the added cost.
That said, I think there is a larger, more fundamental problem with your approach of attempting to add a time cost to your analysis to model fares. The transit schedules are in a lookup table, and the transit evaluator queries this table for the time of day when the traveler arrives at the initial stop for that segment. The schedules are very specific and exact. Let's say the traveler departs on a bus at 8am along a particular segment where you have placed one of those point barriers. Normally the bus takes 10 minutes to reach the next stop, so when the solver queries the transit schedules to determine the cost to traverse the next segment along the transit line, it will be looking for trips that start at 8:10 along that segment, and it will see that the same bus that the traveler is already on does that, and the traveler will just zoom right through in a logical and realistic manner. But if your point barrier adds 50 minutes to the trip, the traveler now arrives at the next stop at 9:00 instead, and the schedules are queried for 9:00. The transit schedules could be completely different by that point, and the traveler might have to sit and wait for the next bus, or it might find that the most efficient path from A to B is now to walk or ride some other transit line. Modeling monetary cost as time in this situation just isn't going to work.
Here is a possible explanation of why you're not seeing a difference in your Service Area. Service Area just searches outward from the Facility to find all possible network segments that are reachable within the time limit, and then it creates a polygon around them. It's possible that all the network segments are reachable either without transit or using some alternative transit lines, so the time delay you put on the one segment didn't make any difference to the total segments reachable. If you have a really dense transit network, this could reasonably happen. Alternatively, if your transit is so infrequent and not timed to correspond to whatever your Service Area start time is, it's possible that the Service Area basically just reflects walking anyway, and the transit wasn't contributing anything in the first place.
You said you want to model some kind of "generalized cost", which I presume is some way of measuring the desirability of transit trips or an annoyance factor or something like that, which incorporates not only raw travel time but also fares and maybe some other less tangible costs. I think a better solution might be to create a separate cost attribute on the network to model monetary cost, and then accumulate this attribute while solving optimizing based on travel time. In the results, you can see the unchanged total travel time, but you can also check the accumulated value of the monetary cost according to how many of your point barriers it traversed. Possibly you could extrapolate beyond that to other, more complex cost attributes to accumulate, depending on your needs. I haven't fully thought through how that would work, but I think there are definitely possibilities here.
Finally, I presume you have some reason for using ArcMap and the deprecated tools, but you, and anyone reading this, are highly encouraged to migrate to ArcGIS Pro and the built-in tools for public transit analysis there.