Q:

Are ViewBags appropriate for passing scalar values to the View from Controller?

When I first learned MVC 5 (a few months ago), I saw frequently in the tutorials  "People use ViewBags to fill dropdownlists in forms. You shouldn't use ViewBag, but for this example, we'll use it (that is -- we'll do the thing that we shouldn't do, rather than show you what you should be doing)."
The correct action, I have been told, is to create a ViewModel. When you are doing (using database language) a table join, or transforming properties in the data model so they appear as desired in the ViewModel, this makes perfect sense. 
However, what if you are trying to pass scalar data one-way from the Controller to the View? If those scalar values are dependent on values passed into the Controller Action parameters and are not tabular in fashion, is a ViewBag such a bad thing?
I have pasted a concept showing where I am getting at. So if my ViewModel should contain (what is in my mind) two distinct categories of information that take two different forms, then what is the appropriate way to communicate those scalar value if not a ViewBag?

I even tried this in my ViewModel, but it did not work as intended for reasons that I think make sense because of the posted image. I need "SelectedCampus" to be passed to the View so that other clickable links and jQuery can use it as a parameter value, but I don't intend for it to be tabular. I only intend for the tabular data to show in the table on the View.
A common response is, "Why not just add that property to your ViewModel?" Here is my mental block: the data model is a table, which might contain hundreds of records.
A scalar value is a single value. If I add a scalar value to a table (i.e., what amounts as a constant value in the table), I'm replicating that scalar value by the number of records. Each scalar value I add adds that much more duplicate information to the table. Now add IEnumerables (i.e., lists which might have more than one column, or not). 
If this were a relational database, my first instinct would be to take out any duplication because the table is no longer normalized. I know, C# is object oriented and is not relational, but hopefully the mental block I have becomes apparent when I question the wisdom of replicating scalar values in a table.
Furthermore, the scalar values are not to be shown in the Table of the View, but rather to populate dropdownlists in the Html.BeginForm block and to supply parameter values for ActionLinks and jQuery functions.  Hopefully this helps to clarify what I am trying to ask.
// ViewModel
public class StudentRosterViewModel
{
    public int ID { get; set; }

    public string Campus { get; set; }

    public string FiscalYear { get; set; }

    public string StudentName { get; set; }

    public int StudentID { get; set; }

    public string SelectedCampus { get; set; }
}

A:

ViewBag is better for simple elements like the page title which aren't really specific to one view, and they're usually in our layout view. Other than that, view models are preferable. It's easier to follow where the data comes from using strongly-typed models. Nearly anything in our view can be traced to the model, and then we can inspect the properties of the model to see where they are set. 
That's lost if our views contain references to @ViewBag.Xyz. It's a bit like throwing away strongly-typed models and replacing them with a Dictionary<string, object>. There's nothing to clearly indicate what any given value should contain, or if it even needs to exist. View models cause the compiler to enforce integrity between the model and the view (and indirectly between the model and the controller.) That goes out the window with ViewBag.
I'm not saying I'd be fanatic about it. There are often exceptions and reasons for doing things. But if someone cuts the corner of placing data in the view model and sticks it in ViewBag instead I'd wonder why. 

